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The  differing  user-computer  interaction  languages, 
implemented  for  conducting  the  same  applications-specific 
functions  on  different  systems,  represent  significant 
stumbling  blocks  to  users.  Toward  alleviating  this  problem 
area,  the  use  of  an  intermediary  processor  to  "uniformize" 
interaction  languages  is  presented,  A  framework  for  such 
processing  is  characterized  in  terms  of  the  required 
intermediary  actions  and  the  logical  capabilities  needed  to 
perform  those  actions.  The  testbed  software  facilities, 
centered  on  the  NBS  Network  Access  Machine,  are  then 
portrayed.  Throughout,  an  example  application,  using  a 
common  command  language  subset  to  access  five  bibliographic 
retrieval  systems,  is  described. 
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1.  INTRODUCTION 


A  considerable  diversity  of  hardware  and  software  has 
been  created  by  manufacturers  of  computer  equipment  and  by 
those  who,  in  utilizing  that  equipment,  provide  various 
kinds  of  applications-oriented  services.  That  diversity  is 
becoming  increasingly  troublesome  to  the  computer  users  or 
service  consumers  who  are  forced  to  cope  with  the  resulting 
system  inconsistencies  and  incongruities, 

1.1  Purpose  and  Overview 

This  paper  is  to  present  a  framework  for  performing 
studies  of  user-computer  interaction  languages.  It  is  based 
on  a  testbed  facility  developed  and  available  at  the 
National  Bureau  of  Standards.  More  specifically,  the 
framework  encompasses  the  ability  to  focus  on  a  set  of 
systems  (called  object  systems)  designed  to  carry  out 
essentially  identical  applications-  specific  functions. 
Thus,  for  example,  we  can  consider  "text  editing"  language 
design  with  regard  to  a  set  of  different  text  editors 
available;  or  we  can  study  the  language  for  accomplishing 
FORTRAN  program  compilation  by  accessing  a  set  of  different 
FORTRAN  compilers  available.  Each  such  set  exhibits 
similarities  in  function  but  differences  in  associated 
user-computer  interaction  language. 

For  the  particular  demonstration  of  our  testbed 
facilities,  a  set  of  five  on-line  bibliographic  retrieval 
systems  was  employed.  Utilizing  the  NBS  Network  Access 
Machine  as  an  intermediary  processor  or  translator  of  the 
interaction        languages  involved,  the  differing 

implementations  of  command  language  were  "unif ormized"  into 
a  common  language.  This  approach  and  the  actions  and 
capabilities  required  to  carry  it  out  are  described  in 
Sections  2  and  3  respectively.  Section  4  then  presents  an 
overview  of  NBS  testbed  facilities  which  are  able  to  meet 
those  requirements.  Finally,  the  considerations  in 
designing  our  example  common  command  language  (for 
bibliographic  retrieval) ,  to  be  employed  on  the  user  side  of 
the  uniformizing  intermediary  processor,  are  described  in 
Section  5  with  references  to  detailed  examples  in  the 
appendixes.  Several  conclusions  from  this  work  are  outlined 
in  Section  6. 

It  should  be  pointed  out  that  the  testbed  facilities 
are  as  yet  limited  to  application  to  the  kind  of 
well-defined,  homogeneous  set  of  command  languages  mentioned 
above.  However,  they  have  the  potential  for  considerable 
expansion  and  improvement.  Furthermore,  the  particular 
command  language  subset  suggested  and  used  as  a  command 
language  for  bibliographic  retrieval  (in  Section  5)  is  not 
being  proposed  as  a  "standard"  language.  It  is  instead  to 
be  viewed  as  an  example  version  which  could  be  tested, 
according      to    various    criteria,     against    other  proposed 
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languages.  As  a  result  of  further  research  and  testing, 
hopefully  producing  meaningful  measures  and  criteria  for 
evaluating  interaction  languages,  it  may  then  become 
possible  to  develop  user-oriented  standards. 


1.2  Interfacing  Users  and  Computers 

The  design  of  the  interface  between  users,  or  human 
information  processors,  and  their  artificial  counterparts, 
namely  computers,  is  a  very  difficult  task.  That  difficulty 
was  undoubtedly  a  major  factor  in  the  relative  neglect  of 
user  needs  until  fairly  recently.  However,  professionals  in 
computer  science  and  related  disciplines  are  now  becoming 
increasingly  sensitive  to  the  importance  of  user-oriented 
systems  design. 

Evidence  to  corroborate  an  increase  in  user  orientation 
includes  the  enlarging  body  of  pertinent  literature  (e.g., 
Bennett  [1972],  Foley  and  Wallace  [1974],  and  Rouse  [1975]); 
the  activities  of  certain  major  special  interest  groups, 
e.g.,  the  ACM/SIGGRAPH  [Treu,  1977a];  and  sponsorship  of 
international  forums  such  as  the  NATO  Advanced  Studies 
Institute  on  Man-Computer  Interaction,  conducted  in  Greece 
in  September  1976.  It  is  also  evident  that  the  Federal 
Government,  through  agencies  such  as  the  National  Bureau  of 
Standards,  is  actively  fostering  and  pursuing  user-oriented 
approaches  to  computer  systems  design,  service,  and 
evaluation.  That  is  born  out  by  this  as  well  as  a 
considerable  series  of  previous  reports  and  papers  (e.g., 
Pyke  [1973],  Blanc  [1974],  Abrams  and  Cotton  [1975], 
Rosenthal  [1976a] ,  Abrams  and  Treu  [1977] ,  Mamrak  and  Amer 
[1979]). 

In  order  to  achieve  a  user-oriented  computer  interface, 
numerous  considerations  must  in  general  be  taken  into 
account  (e.g.,  Treu  [1977b]).  They  range  from 
psychological/physiological  questions  about  the  user  to 
software/hardware  concerns  about  the  computer.  In  this 
report,  the  emphasis  is  only  on  one  constituent  of  the 
interface:  the  user-computer  interaction  language 
encompassing  both  the  user  commands  and  the  system 
responses.  However,  that  is  probably  the  most  significant 
constituent.  The  objective  in  this  project  is  to  overcome 
some  of  the  previously  mentioned  diversity  in  computer 
service  implementations  by  providing  the  user  with  a  special 
type  of  "uniformity"  in  interaction  language. 
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1.3  Interaction  Language 

The  average  American  traveller  appreciates  the  fact 
that  he  or  she  can  speak  English  in  many  foreign  countries, 
instead  of  having  to  learn  French,  German,  Japanese,  etc. 
Likewise,  the  average  computer  user  surely  would  prefer  to 
speak  one  interaction  language  to  accomplish  essentially  the 
same  tasks  in  each  of  a  variety  of  different  computer 
systems . 


1.3.1  Motivating  Example 

Suppose  that  a  user  has  become  familiar  with  a 
particular  interactive  bibliographic  retrieval  system  from 
which  the  following  command, 

FIND  Subject  Term  A  AND  Subject  Term  B  [CR] 

will  elicit  a  response  giving  the  number  of  bibliographic 
citations  in  the  system's  database  which  are  concerned  with 
the  logical  conjunction  of  subject  terms  A  and  B.  In 
responding  to  the  above  search  command,  the  system  also 
assigns  a  sequential  search  statement  number  to  it.  The 
user  can  thereby  make  later  reference  to  that  statement 
within  the  context  of  a  subsequently  entered  search  command. 
For  example,  if  the  assigned  statement  number  is  N,  the  user 
could  use  it  in  a  compounded  search  request  such  as: 

FIND  N  AND  Subject  Term  C  [CR] 

If  that  same  user  now  accesses  a  certain  other 
interactive  bibliographic  retrieval  system,  the  very  same 
search  objective  involving  the  same  kind  of  database  has  to 
be  accomplished  as  follows: 

SELECT  Subject  Term  A  [CR] 

succeeded  by  a  system  response,  giving  the  number  of 
relevant  citations  and  assigning  a  sequential  reference 
number,  say  m.     The  user  must  then  proceed  with: 

SELECT  Subject  Term  B  [CR] 

and  expect  another  system  response,  including  reference 
number  n.     Finally,  the  user  must  issue  the  command: 

COMBINE  m  AND  n  [CR] 

to  arrive  at  the  same  kind  of  system  response  which  was 
produced  with  the  first  system  after  only  entering  the  FIND 
command . 
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This  example  is  only  one  illustration  of  the 
inconsistencies  in  language  that  have  resulted  from 
differing  implementations  even  when  identical  applications 
(e.g.  bibliographic  retrieval)  are  involved.  Such 
inconsistencies  become  even  more  cumbersome  and  confusing  to 
users  when  more  than  two  applications-  specific  systems  are 
considered.  They  are  confounded  still  further  when  situated 
in  more  general,  multi-purpose  systems. 


1.3.2  Accommodating  Users 

We  are  led  to  ask  some  pertinent  questions  about 
interaction  language  design:  Whose  needs  should  be 
accommodated,  the  computer's  or  the  user's?  Should  we 
attempt  to  standardize  interaction  language  or  is  some  kind 
of  compromise  solution  available,  providing  at  least  partial 
relief  for  users  without  imposing  language  standards  on 
anyone? 

While  sociologists,  psychologists,  linguists,  and 
educators  may  study  and  explore  ways  of  improving 
communication  among  people,  including  various  modes  of 
interpersonal  collaboration  [Chapanis,  1975] ,  any  attempts 
to  influence  communication  means  and  methods  are  distinctly 
constrained  by  the  fundamental  fact  that  human  information 
processors  are  so  individally  different  and  relatively 
uncontrollable.  However,  the  latter  is  not  true  of 
computers.  Computer  systems  can  be  controlled  and  modified 
in  their  behaviors  even  though,  like  users,  they  may  be 
individually  different  as  a  result  of  differing 
implementations . 

In  view  of  the  above,  it  seems  reasonable  that,  if 
given  the  choice  between  already  experienced  (or 
conditioned)  users  and  existing  (or  operational)  computers, 
we  should  modify  the  computers  to  be  suitable  for 
communication  by  users  rather  than  vice  versa.  Few  users 
who  have  acquired  a  distinct  dialect  for  talking  with  a 
certain  computer  are  likely  to  want  to  learn  a  markedly 
different  dialect  in  trying  to  access  other  systems  serving 
similar  or  identical  functions. 

On  the  other  hand,  while  the  computers  may  be  willing 
to  accommodate  different  user  dialects,  their  managers  may 
not  be.  For  a  variety  of  reasons,  perhaps  based  on  their 
views  or  analyses  of  the  competitive  marketplace,  they  may 
resist  changing  their  system,  e.g.,  in  its  command  language. 
As  a  consequence,  we  continue  to  have  new  users  learn  and 
become  conditioned  to  the  special  interaction  language 
dialect  pertaining  to  one  system.  Then,  when  motivated  to 
access  a  similar  resource  on  a  different  system,  they  find 
they  can't  speak  its  language. 
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The  project  reported  here  represents  an  attempt  to 
enable  language  uniformity,  at  least  for  categories  of 
applicatons-specif ic  systems.  Before  describing  our 
particular  approach,  a  brief  look  at  the  literature 
concerned  with  interaction  language  is  presented. 


1.3.3  Literature  Review 

The  literature  exhibits  a  few  concerted  attempts  to 
address  what  are  termed  "command  languages."  One  of  these 
involved  a  small,  international  conference  which  resulted  in 
the  publication  of  a  set  of  papers,  including  a  review  of 
the  background  of  command  languages  [Enslow,  1975] .  Another 
effort  was  due  to  the  Special  Interest  Group  for  Operating 
Systems  (SIGOPS) ,  which  conducted  a  session  entitled 
"Operating  System  Command  Languages"  at  the  1976  Annual 
Conference  of  the  ACM,  The  four  resulting  papers,  published 
in  the  proceedings,  ranged  from  a  rather  conceptual  view  of 
the  user-  computer  interface  [Cheriton,  1976]  to  a  specific 
implementation  of  a  particular  command  language  [Muchnick, 
1976] . 

As  demonstrated  by  the  above-referenced  papers,  concern 
about  command  languages  has  generally  been  synonymous  with 
asking  about  the  types  of  facilities  and  features  available 
to  a  user  in  "commanding"  the  supervisory  or  operating 
system  to  carry  out  various  functions  or  to  get  at  available 
compilers,  editors,  and  other  software  and  data  processors. 
This  mostly  one-sided,  monitor-level  view,  motivated  by  the 
necessity  of  having  to  use  certain  commands  to  access  system 
resources,  without  really  attempting  to  perform  a 
comprehensive  study  of  the  interaction  language  (including 
system  responses  to  user  commands) ,  is  indicative  of  the 
literature  background.  There  have,  of  course,  been 
suggestions  on  how  command  languages  might  be  improved,  and 
dismay  has  been  expressed  about  the  numerous  inconsistencies 
and  incongruities,  but  the  study  of  user-computer 
interaction  language  theory  and  design,  has  been  lacking. 

Besides  the  above,  various  special-purpose  command 
languages  for  utilizing  particular  kinds  of  application 
packages  or  software  processors,  have  received  some 
attention.  Examples  are  found  in  selected  papers  in  the 
proceedings  of  the  1976  ACM  Symposium  on  Graphic  Languages 
[Berk,  1976]  and  a  report  on  utilizing  a  common  command 
language  for  file  manipulation  [Fitzgerald,  1978] .  However, 
unlike  programming  languages  which  have  been  studied  to 
considerable  extents,  and  for  which  various  language 
constructs  and  standards  have  been  developed  over  the  years, 
command  languages  have,  in  general,  been  neglected. 
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2.     STUDY  APPROACH 


In  the  interest  of  accommodating  user  needs,  without 
imposing  the  requirement  of  interaction  language 
standardization  on  the  computer  system  designers  and  service 
providers,  it  is  possible  to  achieve  a  reasonable 
compromise:  Enable  the  multi-system  user  to  employ  a  single 
interaction  language  by  means  of  an  intermediary 
" unif ormizing"  processor,  at  least  for  a  particular  category 
of  applications-specific  systems. 


2.1  Multi-System  Orientation 

As  already  implied  by  the  above,  the  focus  of  the  work 
described  here  is  not  on  modification  of  any  one  system's 
interaction  language  for  the  sake  of  its  own  clientele.  The 
latter  may  be  quite  satisfied  with  what  they  have, 
especially  if  they  have  not  tried  other,  perhaps  better 
versions.  Concern  is  instead  for  those  experienced  users 
who  do  want  to  access  a  variety  of  systems  presenting 
similar  (as  well  as  different)  resources.  Concern  is  also 
for  the  increasingly  sophisticated  new  users  who,  unlike 
their  predecessor  generation  of  users,  are  quite  aware  of 
the  multiplicity  of  systems  available  and  are  interested  in 
shopping  around  and  "playing  the  field."  They  are  no  longer 
satisfied  with  having  only  one  system  to  work  with. 

This  multi-system  orientation  suggests  several  possible 
kinds  of  solution.  The  following  three  must  be  rejected  as 
undesirable  or  currently  infeasible: 

1.  The  users  should  be  required  to  learn  the  different 
interaction  language  dialects.  This  would  be 
contrary  to  the  theme  of  this  study  which  is 
user-oriented  design  of  interaction  language.  A 
single  language  usable  on  a  set  of  different 
systems  (with  similar  functions)  is  certainly 
easier  on  a  user  than  a  variety  of  inconsistent 
languages  required  for  the  same  set  of  systems. 

2.  The  object  systems  should  be  required  to  adopt  and 
implement  some  standard  interaction  language, 
designed  for  a  particular  type  of  application  or 
system  category.  This  choice  must  be  rejected 
because  we  do  not  have  appropriate  standards 
developed  as  yet. 

3.  The  object  systems  should  be  required  to  understand 
(i.e.  translate)  all  the  different  language 
dialects  of  different  groups  (and  possibly  even 
individual)  users.  This  option  is  not  feasible 
because  of  the  tremendous  overhead  processing  that 
would  be  incumbent  on  the  object  systems  and, 
furthermore,     considerably      more      research  into 
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language-based  adaptation  (by  the  system  to  the 
user)  is  prerequisite  to  effective  implementation 
of  this  capability. 

Thus,  we  are  left  with  the  following  possible 
solutions: 

4.  An  intermediary  system  should  be  used  to  make  it 
appear  (to  the  users)  that  solution  (2)  has  been 
applied,  without  really  imposing  on  the  object 
systems   (or  their  management) . 

5.  The  intermediary  system  should  be  used  to  make  it 
appear  (to  the  users)  that  solution  (3)  has  been 
applied,  again  without  really  imposing  on  the 
object  systems. 


Solution  (4)  seems  to  be  a  viable  alternative  which,  if 
properly  carried  out,  could  please  both  the  users  and  the 
systems'  managers.  Furthermore,  it  would  have  the  special 
by-product  of  enabling  the  testing  of  proposed  standard 
languages  and  consequently  of  perhaps  convincing  management 
of  the  desirability  of  language  standardization  and/or 
adaptability. 

The  fifth  solution  is  in  a  sense  subsumed  by  (4) ,  but 
only  in  part.  Depending  on  the  power  and  versatility  of  the 
intermediary  processor,  it  could  at  least  provide  the 
testbed  for  a  variety  of  interaction  languages,  thereby 
adapting  to  respective  preferences  of  different  user  groups. 
Although  some  related  work  with  "intelligent  terminals" 
providing  for  limited  "learning"  capabilities  has  been 
carried  out  [Anderson  and  Gillogly,  1976] ,  it  remains 
premature  and,  given  the  state-of-the-art  of  "adaptive" 
systems,  unrealistic  to  suggest  that  such  an  intermediary 
processor  can  be  designed  in  the  near  future  to  be  truly 
adaptive  to  individual  user  language  preferences.  However, 
some  constructive  steps  in  that  direction  are  being  planned 
at  NBS. 


2,2  Intermediary  Uniformizer 

In  accordance  with  the  above-selected  alternative 
(solution  (4)),  the  user's  multi-system  interaction  is  to  be 
facilitated  by  means  of  an  intermediary  system  which  we 
shall  call  a  "uniformizer."  That  is  to  sdy,  the  intermediary 
system  gives  the  appearance  to  the  user  that  a  par^ticular 
interaction  language,  applicable  to  a  particular  level  of  or 
application  in  the  object  system's  resources  repertoire, 
pertains  uniformly  to  each  of  a  number  of  different  object 
systems. 
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The  intermediary  uniformizer  should  ideally  be  totally 
transparent  to  the  user.  However,  that  transparency  is 
currently  not  attainable  in  view  of  some  system 
discrepancies  or  inconsistencies  which  are  difficult  if  not 
impossible  to  reconcile  [Markus  and  Reintjes,  1976]  and 
"unif ormize. "  Hence  the  intermediary  system  may  at  times 
have  to  take  exceptional  or  default  actions  which  will 
inevitably  reveal  its  existence  to  the  user.  Such  problems 
are  not  to  deter  the  objective  of  providing  for  as  much 
uniformity  as  is  reasonably  possible. 


2.3  Selected  Application 

Our  intention  is  to  present  a  general  framework  for 
design  and  testing  of  user-oriented  interaction  language 
which  may  be  applicable  to  a  number  of  different  types  of 
interactive  system  resources.  To  demonstrate  the 
requirements  and  feasibility  of  utilizing  our  testbed 
facilities  (to  be  described  in  the  next  sections)  for 
purposes  of  "unif ormizing"  language,  a  particular  kind  of 
application  was  selected. 


2.3.1  Bibliographic  Retrieval 

It  was  decided  that  the  area  of  on-line  information 
retrieval,  i.e.  retrieval  of  bibliographic  citations,  would 
be  a  good  candidate.  Reasons  included  the  fact  that 
features  of  the  most  prominent  of  such  systems  have  been 
well  described  [Martin,  1974]  both  in  terms  of  commonalities 
and  differences.  Systems  of  that  type  are  also  reasonably 
self-contained  and  well-defined  in  terms  of  applicable 
retrieval  or  retrieval-related  functions  and  hence  in 
required  user-issued  commands. 

Nevertheless,  in  spite  of  the  functional  similarities, 
there  are  enough  differences  among  bibliographic  information 
retrieval  languages  and  their  implementations  to  warrant  the 
facilitation  of  user  access  through  a  common  command 
language.  This  fact  is  confirmed  both  by  Martin  [1974] ,  who 
suggested  that  investigation  of  uniformity  in  commands  be 
carried  out,  and  also  by  the  NSF-sponsored  study  by  Marcus 
and  Reintjes  [1976]  at  M.I.T.,  involving  "coupling"  of 
retrieval  systems.  The  differences  among  the  user-issued, 
retrieval-related  commands  generally  fall  into  three 
categories  (and  combinations  thereof) : 

1.     Semantic:     Two    different    command    verbs    used  to 

achieve      essentially      the    same  results    in  two 

different  systems  (e.g.  NEIGHBOR  and  EXPAND  to 
output  related  vocabulary  terms) . 
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2.  Syntactic:  Different  sequencing  or  delimitting  of 
command  components  within  similar  commands  used  on 
different  systems. 

3.  Scenario:  Beyond  one-to-one  distinctions  between 
similar  commands,  the  differences  between  scenarios 
of  commands  used  on  different  systems  to  accomplish 
the  same  functions.  An  example  was  given  in 
Section  1.2.1. 


A  similar  characterization 
differences  in  the  responses 
primary  attention  in  this  study 
the  discrepancies  in  user-input 


can  also  be  made  of  the 
from  different  systems.  Our 
was  focussed  on  overcoming 
commands . 


2.3.2  Operational  Systems 

Fortunately  a  number  of  operational  systems  providing 
useful  bibliographic  retrieval  services  were  made  available. 
Five  systems  were  selected.  In  alphabetical  order,  they 
are: 

1.  BASIS 

-Battelle  Memorial  Institute 

2 .  DIALOG 

-Lockheed 

3.  MEDLINE 

-National  Library  of  Medicine 

4.  ORBIT 

-Systems  Development  Corporation 
-Close  relative  of  MEDLINE 

5 .  RECON 

-Energy  Research  and  Development  Administration 
-Relative  of  DIALOG 

All  of  these  systems  were  accessible  via  the  Tymshare 
Network  in  case  the  same  communications  medium  was  to  be 
employed.  However,  the  testbed  facilities  are  not 
constrained  to  any  particular  communication  setup  or 
facility.  Two  of  the  above  systems,  ORBIT  and  DIALOG,  will 
be  referenced  almost  exclusively  in  this  report  for  purposes 
of  illustrative  examples. 


2.3.3  Retrieval  Functions 

Each  of  the  sample  set  of  five  systems  serves  the  need 
of  storing  and  then  enabling  users  to  retrieve  bibliographic 
citations  in  various  specialty  areas  and  in  response  to 
user-specified  search  logic.  Although  their  files  may  be 
different,  the  substantive  functions  to  be  carried  out  are 
conceptually  quite  similar. 
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The  major  substantive  functions  are  listed  in  the  left 
column  of  Figure  1:     The  user  can 

1.  Request  identification  of  all  the  files  or 
databases  that  are  searchable  in  a  given  system; 

2.  Select  the  particular  file  of  interest; 

3.  Ask  for  a  display  of  the  search  term  vocabulary, 
which  may  be  structured  alphabetically  and/or 
hierarchically  in  different  systems; 

4.  Specify  and  initiate  a  search  of  the  selected  file, 
based  on  a  logical  (Boolean)  combination  of  search 
terms  (from  the  vocabulary)  and  pertinent 
qualifiers; 

5.  Based  on  a  search  (4  above),  request  the  output  of 
a  specified  number  of  responding  citations,  in 
accordance  with  some  output  format. 


Besides  the  substantive  functions,  similarity  also 
exists  in  the  facilitative  and  connective  types  of 
functions,  which  are  far  less  applications-dependent.  As 
shown  in  Figure  1,  a  user  must  be  able  to  identify  the 
desired  retrieval  system,  connect  and  login  and  later,  after 
completing  an  on-line  session,  logout  again.  In  the 
meantime,  various  facilitative  capabilities,  involving 
explanatory  and  procedural  help  as  well  as  administrative 
assistance  (input  editing  and  output  interruption)  should  be 
provided. 

Figure  1  thus  presents  a  capsule  view  of  the  subset  of 
retrieval-related  functions  selected  for  this  study. 
Ideally,  in  an  application  of  this  kind  in  which 
user-perceived  uniformity  is  to  be  provided  across  a  number 
of  systems,  one  would  like  to  include  all  possible  functions 
and  design  a  correspondingly  all-inclusive  command  language. 
However,  due  to  the  well-established  fact  that  different 
system  implementations  can  render  certain  function-specific 
commands  irreconcilable,  only  a  major  subset  of  functions 
was  addressed.  It  was  deemed  to  be  realistic  and  powerful 
enough  to  make  the  experimental  application  productive 
within  a  resonably  short  time  period. 

3.     TRANSACTION  PROCESSING 

Because  software  and  hardware  implementations  tend  to 
be  constrained  by  particular  language  characteristics  and 
hardware  features,  the  intermediary  processor  which  plays 
our  language  uniformizer  role  should  first  be  defined  in 
terms  of  functional    actions    and    capabilities.      The  more 
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general  framework  for  intermediary  processing  of  the 
user-system  transactions  can  thereby  be  portrayed.  The 
practical  instantiation  of  that  framework  using  our  testbed 
facilities  can  subsequently  be  described  more  meaningfully 
(in  Section  4) . 


3.1  Design  Framework 

Up  to  this  point,  we  have  advocated  user-oriented 
design  of  the  language  interface  by  means  of  employing  an 
intermediary  processor  to  facilitate  the  interaction  between 
the  user  and  any  one  of  a  set  of  accessible  systems.  This 
transaction  model  is  depicted  in  Figure  2.  The  intermediary 
processor  is  to  uniformize  the  different  interaction 
languages,  implemented  for  the  object  systems  respectively, 
by  enabling  the  user  to  utilize  one  common  language  for  all 
of  them.  Since  the  application  for  which  this  intermediary 
processing  approach  was  to  be  demonstrated  is  bibliographic 
information  retrieval,  the  design  of  a  suitable  common 
retrieval  language  was  part  of  our  effort.  The  criteria  for 
doing  so  are  discussed  in  Section  5. 

In  this  Section,  the  design  of  the  intermediary  system, 
i.e.  the  uniformizer,  is  considered  in  terms  of  the 
required  functional  actions  and  capabilities. 


3.2  Intermediary  Actions 

Assuming  that  the  user  has  already  gained  access  to  the 
selected  object  system,  via  a  brief  interchange  with  the 
uniformizer  (see  Figure  2) ,  and  is  now  working  at  the 
regular  user-system  transaction  level  involving  some 
monitor-level  or  applications-specific  software  processor, 
the  user  imputs  and  system  outputs  can  be  distinguished  as 
follows:  the  user  either  commands  the  system  to  do 
something,  explicitly  or  implicitly  (by  asking  a  question) 
or  the  user  responds  to  the  system  by  answering  specific 
questions  (e.g.  input  of  parameter  value  or  choice  of 
available  options) . 

The  "system,"  on  the  other  hand,  which  is  presently 
used  with  reference  to  either  the  intermediary  or  the  object 
system,  reacts  to  inputs  (consisting  of  above-  indicated 
commands  or  answers)  by  either  accomplishing  the  required 
processing  (if  possible) ,  sending  appropriate  messages 
and/or  requesting  additional  input. 

Given  the  general  possibilities  and  distinctions 
suggested  above,  we  can  now  characterize  the  actions 
required  of  the  uniformizer  in  carrying  out  its  intermediary 
role  between  the  user  and  the  remote,  object  system: 
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The  user  issues  a  command  or  answer  intended  for 
the  object  (sub) system  (but  possibly  needed  by  the 
uniformizer) ;     Go  to  Step  2. 

The  uniformizer  intercepts  the  command  or  the 
answer,  parses  it,  and  takes  one  of  the  following 
actions : 


a.  Forwards  it  unchanged  to  the  object  system; 
Go  to  step  3. 

b.  Constructs  revised  command  and  transmits  it  to 
the  object  system;     Go  to  Step  3. 

c.  Reacts  to  the  user  by  transmitting  a  message 
which  either 

(1)  Requires  additional  or  alternate  input; 
Go  to  Step  1:  or 

(2)  Is  a  terminal/default  message;  Go  to 
Step  1. 

The  object  system  receives  the  command  or  the 
answer  and  carries  out  one  of  the  following: 

a.  Performs  the  intended  function  and  transmits 
result  or  acknowledgement  to  the  user  or  possibly 
only  the  uniformizer  which  may    need     it;       Go  to 
Step  4. 

b.  Declines  or  fails  to  perform  the  intended 
function  due  to  one  or  more  of 

(1)  Lack  of  capability 

(2)  Inaccurate  input  parameter 

(3)  Error  condition 

and  transmits  an  identifiable  (by  the  uniformizer) 
message  back  to  the  user;     Go  to  Step  4. 

The  uniformizer  intercepts  the  system  response  or 

message,  parses  it,  and  takes  one  of  the  following 
actions : 

a.  Forwards  it  unchanged  to  the  user;  Go  to  Step 
1. 

b.  Constructs  revised  system  response  and 
transmits  it  to  the  user;  Go  to  Step  1. 

c.  Reacts  to  the  system  by  transmitting  a  command 
which  either 
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(1)  Requires  additional  result;  Go  to  Step 
3 ;  or 

(2)  Requests  clarification  of  prbblem  or 
error  condition;     Go  to  Step  3. 

These  functional  steps  can  be  portrayed  graphically  by 
means  of  the  flowchart  of  Figure  3.  Two  particular 
characteristics  become  apparent:  first,  the  inherent 
symmetry  in  the  treatments  by  the  uniformizer  of  the  user 
input  and  system  output  respectively;  secondly,  within  that 
symmetry,  the  interactive  nature  of  user-unif ormizer 
communication  until  a  command  is  ready  for  transmission  to 
the  system,  and  likewise  of  system-unif ormizer  communication 
until  a  response  is  ready  for  transmisson  to  the  user. 
Notice  that,  ideally,  the  uniformizer  should  also  be  capable 
of  deciding  whether  a  user  input  is  legal  or  safe  for 
(understandable  reaction  by)  the  system  and  whether,  on  the 
other  hand,  a  system  response  (e.g.,  error  message)  is 
adequately  clear  for  the  user. 


3.3  Required  Capabilities 

In  order  to  enable  the  above-indicated  intermediary 
actions,  the  uniformizer  must  not  only  have  the 
communications-related  capabilities  of  receiving  messages 
from  and  transmitting  messages  to  each  of  the  other 
processors  but  it  must  also  be  prepared  to  carry  out  any 
required  processing  of  messages  in  its  possession  at  any 
given  time.  The  latter  necessitates  the  development  and 
implementation  of  appropriate  algorithms  so  that  the 
"parsing"  of  messages  or  the  "construction"  of  revised 
commands  or  the  other  actions  suggested  in  Section  3.2  can 
in  fact  take  place. 

The  following  five  types  of  fundamental  capabilities 
seem  to  be  required  of  the  uniformizer  to  enable  it  to  carry 
out  the  essential  transaction  processing  and  message 
transformation : 

1.  Matching  of  character  strings, 

2.  Selection  of  message  components, 

3.  (Re) construction  of  messages, 

4.  Mapping  of  message  sequences,  and 

5.  Handling  of  contingencies. 
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FIGURE  3.  UNIFORMIZER  PROCESSING  OF  INPUT/OUTPUT 
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The  above  are  interdependent  or  mutually  supportive  in 
that  they  (or  a  subset  of  them)  may  have  to  be  employed  in 
combination  or  in  immediate  succession.  As  can  be  observed 
from  their  respective  descriptions  in  the  following 
subsections,  these  capabilities  pertain  specifically  to 
message  processing  under  the  assumptions  that 

1.  The  messages  are  constituents  of  one  or  more 
clearly  defined  artificial  interaction  language (s) 
thereby  avoiding  most  of  the  problems  of  dealing 
with  natural  language  parsing  and  grammatical 
manipulation,  and 

2.  An  adequate  body  of  knowledge,  or  enough 
"intelligence,"  resides  in  the  intermediary  system 
to  support  the  required  processing  of  such 
languages . 


In  each  of  the  descriptions  that  follow,  an 
illustrative  example  is  given  based  on  transactions  or 
messages  involved  in  our  selected  bibliographic  retrieval 
application . 

3.3.1  Matching  of  Character  Strings 
Given  the  following  conditions: 

1.  The  uniformizer  has  received  any  message,  i.e., 
character  string,  consisting  of  n  alphanumeric 
characters,   for  n  >  0,  and 

2.  A  reference  point  i  has  been  established,  either 
explicitly  or  implicitly  during  interprocessor 
interaction,  to  focus  on  the  substring  starting 
with  the  ith  character  in  the  message,  for  1  £  i  £ 
n. 


the  system  must  be  able  to  effectively  determine  matches  or 
mismatches  between  that  message  substring  and  another 
character  string  which  is  either  already  stored  in  its 
resident  knowledge  base  or  explicitly  supplied  by  one  of  the 
two  communicating  processors. 

Subsequent  uniformizer  actions  are  then  contingent  on 
the  outcome  of  the  specific  character  string  matching.  This 
fundamental  capability  clearly  suggests  that  the 
intermediary  system  employed  for  this  role  should  be 
equipped  with  software  which  facilitates  efficient  character 
string  storage  and  manipulation. 

Example:     When  the     user     wishes     to    command  the 
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system  to  display  one  of  several  different 
types  of  available  information,  e.g.  a  list 
of  names  of  searchable  files  or  a  list  of 
search  terms  related  to  some  specified  term 
or  a  specified  number  of  responsive 
citations,  then  the  following  "common" 
command  format  is  suitable  in  all  cases. 

DISPLAY  <Argument (s) >  [CR] 

Upon  interception  of  this  message,  the  first  several 
characters  (starting  at  i=l)  must  be  matched  against  known 
types  of  commands  to  identify  the  command  category  involved. 
Then,  at  the  hierarchically  next  level,  the  argument 
character  string  (starting  at  i=9  in  above  command)  must  be 
matched  against  the  known  options  that  apply  to  the  DISPLAY 
command.  The  uniformizer  can  then  take  the  action (s) 
required  by  the  user-specified  option  in  order  to  transform 
the  message  appropriately. 


3.3.2  Selection  of  Components 

Given  a  more  macro  view  of  a  communicated  message,  in 
the  context  of  a  well-defined  artificial  (as  opposed  to 
natural)  language,  it  can  be  considered  as  consisting  of  a 
string  or  sequence  of  components.  Each  of  these  is  nothing 
but  a  character  substring  which  is  properly  delimited  and  in 
the  proper  sequential  location  of  the  component  string. 

Thus,  given  the  following  conditions: 

1.  The  uniformizer  has  received  any  message,  i.e., 
component  string,  consisting  of  m  components  or 
parameters,  for  m  >^  0,  and 

2.  A  reference  point  j  has  been  established,  either 
explicitly  or  implicitly  during  interprocessor 
interaction,  to  focus  on  the  jth  component,  for  1  < 
j  <  m. 


the  system  must  be  able  to  effectively  address  that 
component  for  purposes  of  utilizing  the  character  string 
matching  capability  (described  in  the  previous  subsection) 
and/or  the  message  (re) construction  capability  (described  in 
the  next  subsection) .  The  latter  alternative  really 
justifies  this  "component  selection"  as  a  separately 
described  capability  (distinct  from  character  string 
matching)  in  that  at  times  the  uniformizer  need  not  match 
the  jth  component  with  anything  but  rather  need  simply 
locate  and  replace  it  with  a  different  component  or 
parameter . 

Example:     In  response  to  a  user  command  to    search  for 
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some  specified  logical  combination  of  subject 
terms,  the  retrieval  system  assigns  a 
sequential  number  N  to  that  search  command 
for  purposes  of  later  reference  by  the  user 
(see  also  Section  1.2.1)  and  then  precedes 
the  search  results  with 

SEARCH  STATEMENT  N: . . . 

Because  this  is  done  consistently  and  because 
the  uniformizer  may  have  to  assign  a 
different  sequential  number  to  that  same 
search  statement  (see  Section  3.3.4  below), 
the  number  N  can  simply  be  viewed  as  the 
third  component  (with  j=3) ,  assuming 
components  are  separated  by  spaces.  That 
component  or  parameter  need  not  be  matched 
against  some  character  string  (unlike  Section 
3.3.1)  but  instead  must  only  be  located  and 
replaced. 


3.3.3   (Re) construction  of  Messages 

Both  above-defined  capabilities  are  in  effect 
prerequisite  to  implementing  the  more  substantive  capability 
which  can  render  different  interaction  languages  to  appear 
uniform  from  the  standpoint  of  the  user.  That  capability  is 
the  construction  or  reconstruction  of  messages  received  by 
the  uniformizer  during  one  or  more  interchanges  with  either 
the  user  or  the  remote  system. 

Thus,  given  the  following  conditions: 

1.  The  uniformizer  has  received  one  out  of  the  known 
set  of  k  (types  of)  messages  available  to  the  user 
in  the  common  language,  or  one  out  of  the  known  set 
of  r  (types  of)  responses  reproducible  by  the  jth 
remote  system,  and 

2.  That  message  is  identified  to  be  a  particular  type, 
by  means  of  the  previously  defined  capabilities  or 
through  sensitivity  to  the  context  of  known  (or 
expected)   interchange  sequences. 


the  system  must  be  able  to  transform  that  message,  or 
perhaps  utilize  its  substance,  towards  the  ultimate  creation 
of  an  appropriate  command  to  the  remote  system  or  an 
appropriate  response  to  the  user.  Such  transformation  can 
range  from  a  simple  substitution  of  a  component  or  parameter 
(as  suggested  in  the  previous  subsection) ,  to  the 
re-arrangement  of  components,  to  the  total  replacement  of 
the    message    by    an  alternative  form.    To  achieve  that  end. 


19 


the  transformation  may  be 

a.  One-to-one,  in  that  a  single  message  from  the  user 
(or  remote  system)  is  transformed  into  a  single  message  to 
the  remote  system  (or  user) ,  or 

b.  One-to-many,  in  that  a  single  message  from  the  user 
(or  remote  system)  is  broken  down  into  a  succession  of  two 
or  more  messages  to  the  remote  system  (or  user) ,  or 

c.  Many- to-one,  in  that  two  or  more  messages  from  the 
user  (or  remote  system)  are  compiled  into  a  single  message 
transmitted  to  the  remote  system  (or  user). 

Each  choice  of  transformation  will  depend  on  one  or 
more  of:  what  is  required  by  the  remote  system  involved, 
what  is  deemed  to  be  desirable  in  behalf  of  the  user,  and 
the  nature  of  the  common  command  language  that  is  in  fact 
designed  and  its  ability  to  accommodate  both  user  and  system 
needs . 


Example:  A  user  command  to  search  for  a  logical 
combination  of  subject  terms  must  be 
transformed  one-to-one,  into  the 

FIND  <arguments>  [CR] 

command  for  one  retrival  system  (ORBIT) .  On 
the  other  hand,  for  a  different  system 
(DIALOG) ,  it  initiates  a  one-to-many 
transformation  involving  the  following  three 
(or  more)  commands 

SELECT  <search  term>  [CR] 
SELECT  <search  term>  [CR] 
COMBINE  <arguments>  [CR] 
where     <arguments>     consists    of     a  logical 
combination    of     numeric  identifiers  assigned 
by    the    system    to      each      SELECT  command 
respectively.     (See  also  Section  1.2.1). 


3.3.4  Mapping  of  Message  Sequences 

The  three  above-described  capabilities  focus  primarily 
on  the  individual  message-specific  level,  whether  that 
message  is  transmitted  by  the  user  or  the  system.  It 
furthermore  becomes  necessary  for  the  uniformizer  to 
acquire,  structure  and  utilize  certain  kinds  of  "knowledge" 
which  are  session- (or  subsession-)  oriented,  ranging  across 
the  successive  sequence  of  messages  emanating  either  from 
the  user  or  the  system.  This  is  particularly  true  when  a 
one-to-many  transformation   (see  above)   is  involved. 
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when  the  system  creates  an  explicit  interdependence 
between  successive  commands  c  and  c+1  issued  by  the 
uniformizer,  by  assigning  a  sequence  of  numbers  to  them, 
then  the  correspondence  between  each  single  user-input 
command  and  the  multiple  unif ormizer-transmitted  commands 
must  be  developed  and  maintained  for  subsequent  reference. 


Example:  Assuming  that  either  one-to-one  or 
one-to-many  transformations  are  involved  and 
given  the  sequencing  of  search  statements 
mentioned  in  both  of  the  previous  sections, 
the  uniformizer  may  have  to  maintain  the 
following  kind  of  correspondence  between  the 
user-understood  and  the  system-required 
sequences  of  numbers: 

USER  SYSTEM 

1  1,2 

2  3 

3  4,5,6 

4  7,8 

5  9 

Thus,  whenever  the  user  makes  reference  to  one  of  the  search 
statements  already  previously  entered  and  identified  (e.g. 
number  4) ,  the  uniformizer  must  of  course  translate  that 
statement  number  into  the  system-understood  number (s)  (e.g. 
numbers  7  and  8  above) . 

3.3.5  Handling  of  Contingencies 

All  of  the  previously  described  capabilities  require 
backup  to  insure  failsafe  intermediary  operation  in  the 
user-system  communication  channel.  For  example,  a  character 
string,  message  component  or  entire  message  may  be 
out-of-place ,  improperly  delimited  or  unidentifiable.  In 
these  and  other  instances,  the  intermediary  system  must 
either  be  smart  enough  to  take  corrective  action  in  behalf 
of  the  transmitting  party  (user  or  object  system)  or 
otherwise  gracefully  react  with  appropriate  error  messages 
or  diagnostic  inquiries  designed  to  overcome  or  circumvent 
the  problem  situation. 


4.     TESTBED  FACILITIES 

The  functional  requirements  of  the  intermediary 
uniformizer  can  now  be  exemplified  through  a  realistic 
implementation,  using  hardware  and  software  facilities 
available  at  the  National  Bureau  of  Standards. 


4,1  Network  Access  Machine 
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A  minicomputer-based  system  has  been  developed  at  the 
National  Bureau  of  Standards  to  enable  the  implementation 
and  testing  of  the  kinds  of  intermediary  functions  described 
in  Section  3.  This  Network  Access  Machine  (or  NAM) 
[Rosenthal,  1976  a  and  b]  can  provide  a  user  with  automatic 
access  to  any  of  the  large  assortment  of  remotely 
accessible,  interactive  computer  services.  It  does  this,  in 
general,  by  allowing  a  user  terminal  to  connect  (or  dial  in) 
to  it,  then  establishing  the  appropriate  communications 
connection  to  the  remote  host  requested  by  the  user,  and 
then  carrying  out  the  previously  described  intermediary 
action  roles  until  it  is  time  to  sever  the  user-system 
connection. 

More  specifically,  the  NAM  is  actually  a  non-privileged 
user  program  which  runs  under  the  UNIX  operating  system.  It 
can  thereby  take  advantage  of  UNIX  capabilities  and,  as  a 
result,  it  reflects  some  of  these  in  terms  of  what  it  can 
accomplish  and  how.  The  intention  here  is  not  to  describe 
UNIX  or  the  NAM  in  their  full  technical  detail.  Such 
description  has  already  been  produced  by  Rosenthal  and  Lucas 
[1978] .  Instead,  this  report  only  highlights  those  special 
characteristics,  such  as  in  communication  modes  and  language 
constructs,  which  can  support  the  "unif ormizer "  requirements 
outlined  in  Section  3.  This  section  should  therefore 
provide  a  general  appreciation  of  what  is  logically 
possible . 


4.2  Communication  Modes 

A  user  wishing  to  access  a  remote  system  via  the  NAM 
must  establish  a  hardwire  or  dial-up  connection  to  the  UNIX 
machine  and  then  carry  out  the  required  login  procedure 
(including  speed  detection  for  the  user's  terminal). 
Subsequently r  the  user  has  the  repertoire  of  NAM/UNIX 
commands  available  to  connect  and  then  interact  with  the 
remote  system  in  various  direct  or  indirect  (i.e., 
intermediary  assisted)  ways.  The  command  types  and 
constructs  will  be  characterized  below. 

Before  doing  so,   it  is  important  to  recognize  that  the 
user  has  a  choice  between  two  basic  modes  of  communication: 

1.  Priority  or  default  communication  with  the  NAM, 
while  direct  interaction  with  the  remote  host  is 
optional. 

2.  Direct  store-and-f orward  communication  with  the 
remote  host,  while  interaction  with  the  NAM  is 
optional. 
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A  particular  command  (.Remote  (Specified  Host))  invokes 
the  store-and-f orward  mode;  a  special  character  (control 
back-arrow)   returns  communication  to  the  NAM  mode. 

4.3    NAM  Command  Repertoire 

Three  basic  types  of  commands  are  available  to  the  NAM 
user:  regular  UNIX  commands,  macro  directives  (or  "quick 
verbs")  and  macro  names.  These  are  supplemented  by  a  set  of 
string  manipulation  capabilities.  All  will  be  defined  and 
discussed  more  fully  in  following  subsections. 
Collectively,  they  represent  the  repertoire  of  commands 
available  to  the  user  (or  representative  of  users)  for 
purposes  of  constructing  the  intermediary  libraries  of 
software  procedures  or  constructs  which  can  serve  the 
objective  of  achieving  uniformity  in  interaction  language. 
That  is  to  say,  the  intermediary  system  can  thereby  be 
equipped  with  the  required  transmission,  translation,  and 
analysis  capabilities  which  will  support  the  appearance  of 
language  uniformity  to  individual  and/or  groups  of  users. 
In  particular,  the  syntax  and  semantics  of  the  uniform 
language  are  based  on  the  defined  macros  and  the  specific 
arguments  which  those  macros  accept. 

The  three  types  of  commands  are  distinguished  by  means 
of  differing  preceding  special  characters  (or  lack  thereof) 
on  input  to  the  NAM. 


4.3.1  UNIX  Commands 

The  various  UNIX  commands  and  subsystems  are  utilized 
in  the  creation  and  maintenance  of  macros.  All  UNIX 
commands  as  well  as  the  UNIX  editor  are  available  to  the  NAM 
user.  A  user-input  command  is  assumed  to  be  a  UNIX  command 
if  no  special  prefix  character  is  typed.  This  default 
treatment  is  easily  changed  to  apply  to  the  macro  commands 
instead . 

Example  UNIX  commands  are: 


Filename 


Function 


To  format  output  for  printout 


time 


To  determine  time 


who 


To  determine  who  is  on  system 


4.3.2  Macro  Directives 
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The  second  type  of  command  is  the  macro  directive  which 
involves  a  "quick  verb"  or  action  request.  It  causes  the 
NAM  to  immediately  carry  out  the  specified  action  relative 
to  such  general  functions  as: 

1.  remote  system  connection/disconnection 

2.  data  transmission,  collection,  and  output 

3.  data  analysis  and  related  conditions 


A  macro  directive  is  distinguished  from  a  UNIX  command 
and  a  macro  name  command  by  preceding  it  with  a  period. 

Examples  of  macro  directives,  most  of    them  indicative 
of  above-indicated  function  categories,  are: 
Form  Specific  Function 


.connect  (argument)   to  establish  hardware 

connection  to  specified 
remote  system  attached 
to  NBS  patch  panel 


to  establish  dial-up 
connection  to  specified 
remote  system  using  automatic 
calling  unit 


to  transmit  specified 
string  to  user  terminal 


to  transmit  specified 
character  string  to  remote 
system;  used  in  conjunction 
with  other  directives,  e.g., 
.match  and  .term 


to  define  the  conditions  (i.e., 
character  strings)   upon  which 
termination  of  remote 
system  response  is  accepted 


to  create  the  conditions 
(i.e.,  character  strings)  which 
define  the  termination  of 
remote  system  response 


.dial  (argument) 


.msg  (argument) 


.send  (argument) 


.match  (argument) 


.term  (argument) 
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.newdir   (argument)     switch  to  specified  working 

directory 


The  previously  mentioned  (in  Section  4.2)  .remote 
command  is  another  example  macro  directive.  All  of  these 
commands  can  either  be  issued  directly  from  the  user 
terminal  or  they  can  be  incorporated  in  macro  definitions 
and  then  executed  upon  calls  to  such  macros.  To  further 
enhance  these  capabilities,  various  UNIX  commands  can  be 
included  within  macros  as  if  they  were  macro  directives. 


Table  1  lists  an  example  macro  which  is  used  in  this 
section  to  illustrate  a  number  of  the  NAM  facilities  being 
discussed.  In  particular,  it  includes  several  of  the  macro 
directives,  e.g.,  .msg  <argument>  and  .send  <argument>, 
identified  above.  Appendix  A  gives  further  examples  of 
macro  directives  within  macro  definitions. 


4.3.3  Conditional  Constructs 

The  commands  described  thus  far  can  be  viewed  as 
building  blocks  for  creating  useful  macros  which  can  then  be 
saved  and,  upon  being  called,  expanded  and  executed  by  the 
intermediary  processor.  But  to  enable  effective  macro 
creation,  conditional  constructs  are  required. 

Thus    a     special      set      of      conditional  directives, 
distinguished     by    being  preceded  with  an  asterisk,  has  been 
implemented.       This     includes     the    well-known  IF-THEN-ELSE 
construct  with  the  following  format: 
*if  <expression> 
..various  directives... 
[*else 

..various  directives...] 
*end 

where  the  optional  ELSE  component  is  bracketed.  Three  of 
these  are  used  in  the  macro  displayed  in  Table  1. 

Also  the  WHILE-DO  construct  is  available: 
*while  <expression> 
..various  directives... 
*end 

See  DIALOG'S  FIND  macro  in  Appendix  A  for  an  example. 
Integer-valued  expressions  are  tested  and  results  determine 
which  directives  are  executed.  A  "switch  to  various  cases," 
which  is  similar  to  the  directed  GO  TO,  is  available  in  the 
following  form: 


♦switch  <expression> 
..various  directives... 
case  <expression> 

. . var  ious  directives . . . 
[etc. ] 
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.string  s 
.int  i 

.term  "t60  !  '? 
.match  "'?'" 

*if  (  userline  ?  ".*  (  'database  names'  I  'file  names'  )  "  ) 
.send  "?files[CR]" 

.msg  response  @  ".*  '?files'  {.*}  '?'" 
.set  scratch  to  response 

.exit 

*end 

*if  (  userline  ?  ".*  (  'terms'  I  'words'  )"  ) 

.set  s  to  userline  @  ".*  'related  to  '{.*}$" 
.send  "expand  "  .  s  .  "[CR]" 

.msg  response  @  ".*  ' [CR] '  {.*>  '-more-'  " 

.exit 

*end 

*if  (  userline  ?  ".*  'citation'"  ) 

.set  i  to  userline  I?  ".*  {/0-9//0-9/*}  '  citation'" 
.send  "type  "  .  flagO  .  '72/1-"  .  i  .  "[CR]" 

.msg  response  @  ".*  ' [CR] '  {.*}  '?  '  " 

.exit 

*end 

.msg  "display  <object>" 

.msg  "<object>  :=  file  names  |  database  names  I  terms  related  to  [" 
.msg  "  words  related  to  |  <number  of>  citations" 

.msg  "<number  of>  :=  a  number" 


Table  1.    The  DISPLAY  macro  (for  DIALOG  System). 
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[*case  <expression> 

..various  directives...] 
*end 


Here  two  or  more  cases  can  be  specified,  and  control  will  be 
transferred  to  that  subset  of  directives  for  which  the 
expression  matches  the  one  in  the  switch  statement. 


4.3.4  String  Manipulation 

To  satisfy  the  functional  requirements  outlined  in 
Section  3.3.  a  set  of  SNOBOL-like  character  string 
manipulation  capabilities  have  been  implemented  [Rosenthal 
and  Lucas,  1978] .  Following  is  a  brief  description  of  each. 
Specific  examples  are  displayed  in  Table  1  and  among  the 
macros  listed  in  Appendix  A. 

Firstly,  both    string    and    numeric    variables    can  be 
declared  by  means  of  the  directives 
.STRING  X  and  .INT  I 

respectively  (see  top    of    Table  1) .      Then    any  desirable 

character     string  or  pattern  can  be  constructed  and  assigned 

to  a  string  variable  by  means  of  the  .set  directive,  e.g. 
.SET  X  to  "ABC" 

This  is  done  for  string  variable  s  in  Table  1.  It  then 
enables  easy  referencing  of  any  character  string,  including 
the  entire  messages  received  from  or  sent  to  either  the  user 
terminal  or  the  remote  system. 

To  perform  the  actual  character  string  manipulations, 
three  binary  operations  are  defined:  concatenation,  string 
matching  and  substring  extraction.  They  are  symbolized  by 
the  characters  .,  ?,  and  @  respectively.  These  operators 
are  interpreted,  along  with  the  various  arithmetic  operators 
(e.g.  +) ,  whenever  the  available  expression  evaluator  is 

invoked.  The  latter  applies  to  the  directives  .msg,  .send., 
and  .set,  and  the  conditional  constructs  *if,  *while, 
*switcl. ,  and  *case. 

The  concatenation  operation  (.)  is  simply  demonstrated 
as  follows: 

.STRING  X  Y 
.SET  X  to  "OUT" 
.SET  Y  to  "PUT" 
.MSG  X   .  Y 

generates  and  transmits  the  following  character  string  to 
the  user  terminal: 

OUTPUT 

In  the  middle  of  Table  1,   this  capability  is  illustrated  by 
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.Send  "expand"   .s.  "[CR]." 


The  string  matching  operation  (?)  involves  the  matching 
of  a  specified  pattern  against  a  string,  using  the 
expression  format 

<string>  ?  <pattern> 

If  a  match  is  determined,  the  expression  value  is  set  to  1 
(i.e.,  TRUE)  and,  if  not,  to  0  (i.e.,  FALSE).  Notice  that 
this  matching  operation  is  used  in  each  logical  expression 
of  the  three  IF-THEN  constructs  in  Table  1.  In  each  case, 
the  pattern  following  the  question  mark  (?)  is  sought  in  the 
user-input  message  called  userline. 

The  third  kind  of  operation,  namely  substring 
extraction  (@) ,  subsumes  the  string  matching  operation  and 
also  produces  a  new  string  based  on  extractions  from  the 
string  in  accordance  with  the  elements  of  the  pattern.  The 
expression  format  is  similar  to  that  for  string  matching: 

<string>  §  <pattern> 

Extraction  results  in  the  return  of  a  (sub) string  of 
characters  extracted  from  the  left-side  string  in  the 
expression.  This  is  essentially  demonstrated  by  the 
following  sample  pattern: 

•'({/0-9/}l.)*$" 

which  extracts  all  numeric  characters  from  the  specified 
string.  For  example,  the  above  pattern  would  cause  the 
extraction  of  numeric  characters  1214  from  string  alb2cld4. 
Another  example  is  given  in  the  third  IF-THEN  clause  of 
Table  1  where  variable  i  is  set  to  the  two-digit  number 
extracted  from  the  string  called  userline. 

The  above  indicated  patterns,  for  either  string 
matching  or  extraction,  must  be  carefully  constructed  into  a 
sequence  of  elements  consisting  of  some  combination  of  the 
following  symbols  and  corresponding  matching  objectives: 


Any  single  character 

/x-y/  Any  character  in  range  x  to  y, 

where  x  and  y  are  single 
characters 


The  sequence  of  characters 
specified  between  the  single 
quotes 
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$  The  null  character  at 

the  end  of  the  string 


Zero  or  more  occurrences 
of  preceding  item 


1  The  OR  operator  separating 

alternative  items 


Given  these  operators  and  their  interpretations, 
following  is  an  example  set  of  string-matching  expressions 
each  of  which  would  be  evaluated  to  be  TRUE: 


"F"  ?  "/C-G/" 

"Go"   ?  "/A-H/  /i-p/" 

"my"  ?  "./x-z/" 

"ijk"  ?  "'ij'" 

"mn"  ?  "'mn'$" 

"abode"  ?  " . * ( ' fg ' 1 ' cd ' ) " 

These  examples  are  only  indicative 
capabilities.  They  nevertheless  suggest 
patterns  can  be  constructed  and  utlized  in 
and  extraction  expressions. 


4.3.5  Macros 

The  UNIX  commands,  macro  directives,  conditional 
constructs,  and  string  manipulation  capabilities  can  now  be 
employed  collectively  to  create  macros.  By  means  of  the 
UNIX  editor,  the  appropriate  commands  can  be  selected, 
sequenced,  and  stored  in  a  file.  The  file  names  themselves 
then  become  constituents  of  the  kind  of  "uniform"  command 
language  which  is  the  primary  object  of  this  report.  That 
is  to  say,  a  user-input  command,  which  is  actually  a  file 
name  preceded  by  the  special  up-arrow  character 
(distinguishing  macros  from  UNIX  commands  and  macro 
directives) ,  invokes  the  macro  expander  and  causes  the 
various  directives  contained  in  the  macro  to  be  executed 
relative  to  the  particular  remote  system  and  interactive 
user . 

Thus,  for  example,  if  the  user  is  already  logged  into 
the  Lockheed  DIALOG  system,  and  wishes  to  use  a  command  of 
the  general  form 

DISPLAY  <argument (s) > [CR] 

where  argument (s)  may  be  a  list  of    available     filenames,  a 


of  available 
how  very  complex 
string-matching 


29 


list  of  search  terms  related  to  a  specified  term,  or  a 
listing  of  N  citations  responsive  to  a  previous  search 
command,  the  macro  shown  in  Table  1  would  be  invoked  and 
executed. 

Other  "real"  object  system  commands  can  be  implemented 
likewise  in  terms  of  macros  cntrolled  by  the  NAM.  They  are 
included  in  Appendix  A,  for  two  of  the  systems  (ORBIT  and 
DIALOG)    involved  in  our  application. 


4.4  Other  Features 

Among  the  useful  features  of  the  macro  expander  are  its 
recursiveness  and  nesting  capabilities.  That  is  to  say,  it 
can  call  upon  itself  repeatedly  as  well  as  call  on  other 
macros  (i.e.,  file  names)  for  their  subsequent  expansion 
within  the  context  of  the  outer   (or  calling)  macro. 

Finally,  the  testbed  faclities  exhibit  certain 
user-oriented  features.  In  particular,  the  user  who  wishes 
to  call  upon  the  various  command  alternatives  previously 
described  can  take  advantage  of  the  TENEX-like  capability 
for  command  completion.  Thus,  a  command  input  in  te 
following  order : 

Special  char   (if  any),  unique  char  string,  Esc/Altmode 

will  be  automatically  completed  by  the  system  and  executed 
as  appropriate. 


5.      LANGUAGE  DESIGN 

In  order  to  utilize  the  framework  of  logical 
capabilities  and  implemented  facilities  (described  in 
Sections  3  and  4  respectively)  for  prov:"  Mng  uniformity  to 
user-computer  interaction  languages,  a  common  command 
language  was  required.  This  language  had  to  be  tailored,  of 
course,  to  the  selected  application,  namely  bibliographic 
retr  ieval. 


5.1  Criteria  for  Command  Language  Design 

Given  a  number  of  different  systems  designed  to  carry 
out  essentially  the  same  kinds  of  application-specific 
functions,  how  does  one  design  a  common  command  language? 
Several  approaches  suggest  themselves,  including  trying  to 
identify  from  among  the  different  command  languages  which 
have  somehow  evolved  those  commands  which  seem  to  have 
gained  majority  acceptance. 
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Another  approach  could  involve  selecting  a  sample  of 
totally  inexperienced  computer  users,  setting  them  in  front 
of  an  on-line  terminal  to  a  retrieval  system  and  asking  them 
how  they  would  command  the  computer  to  retrieve  certain 
bibliographic  citations  for  them.  By  closely  observing, 
recording,  and  analyzing  their  responses,  a  more  "natural" 
and  less  biased  set  of  commands  could  perhaps  be 
construe ted . 

Instead,  the  approach  adopted  .  was  to  use  personal 
experience  and  intuition  in  establishing  a  set  of  design 
criteria  and  then  proceeding  to  develop  the  command  language 
accordingly.  The  resulting  language  is  therefore  not 
proposed  as  a  "standard"  as  such,  but  rather  as  a  flexible 
model  of  what  such  a  language  might  conceivably  resemble. 

The  design  criteria  were: 

1.  The  command  structure  should  adhere  basically  to 
the  format  of  the  "action  primitive"  [Treu,  1975] , 
which  consists  of 

a.  an  action  verb 

b.  qualifier (s)    (if  any)  of  that  action 

c.  an  object  of  the  action 

d.  qualifier (s)    (if  any)  of  the  object 

Whenever  possible  and  reasonable,  these  should  be 
maintained  in  the  indicated  order. 

2.  The  action  verbs,  objects,  and  qualifiers  should  be 
selected  to  be  both  meaningful  (relative  to 
retrieval  system  functions)  as  well  as  versatile 
(e.g.,  in  associating  a  verb  with  several  different 
objects,  or  vice  versa) .     See  criteron  (8) . 

3.  In  view  of  the  above,  the  commands  need  not  be 
consistent  with  some  of  the  commonly  accepted  forms 
which  have  evolved  over  the  years  but  which  were 
normally  not  selected  in  a  deliberative,  systematic 
way.  However,  when  they  happen  to  fit  into  the 
above-suggested  format,   their  inclusion  is  welcome. 

4.  The  action  verbs,  objects,  and  qualifiers  should 
also  be  selected  to  be  mnemonically 
distinguishable,  rendering  each  verb  unique  in  its 
first  several  characters,  and  likewise  for  objects 
and  certain  qualifiers.  See  also  criteria  (9)  and 
(10). 

5.  Because  some  of  the  different  system  functions 
cannot  be  reconciled  via  a  common  language  (at  this 
time),  the  user  should  be  able  to  bypass  or 
supplement  the  common  commands.  To  do  so,  the  user 
should  merely  have  to  precede  any  "real"  command  by 
some     special    character.     Thus,  the  common  command 
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language  represents  the  normal  or  default  mode,  but 
the  user  can  switch  to  the  object  system's  language 
directly  upon  explicit  request, 

6.  To  provide  a  flexible  model  language,  easy 
modification  of  or  substitution  for  any  giveh 
action  verb,  object  or  other  components,  within  the 
established  structure  of  the  language,  should  be 
possible . 

7.  Two  or  more  alternative  versions  of  action  verbs, 
objects,  and  qualifiers  should  be  implemented  from 
the  outset,  as  long  as  they  are  selected  to  avoid 
confusion  with  respect  to  criterion  (4). 

8.  Identical  action  verbs  should  be  used  for  different 
functions  when  the  involved  actions  are  most  likely 
to  be  conceived  by  the  user  as  very  similar  if  not 
exactly  the  same.  An  example  is  the  request  to 
"display"  some  kind  of  information.  The  functions 
can  then  be  distinguished  by  means  of  the  specified 
differing  action  objects. 

9.  The  user  should  be  able  to  specify  only  the  first 
several  characters  and  then  cause  the  intermediary 
system  to  supply  the  remaining  characters  of  each 
known  command  component  automatically,  after  simply 
pressing  the  excape  key. 

10.  In  conjunction  with  the  TENEX-like  behavior 
suggested  by  criterion  (9),  the  language  should 
also  attempt  to  accommodate,  as  possible,  differing 
requirements  of  experienced  and  inexperienced 
users.  A  simple  first  step  is  to  enable  the 
experienced  user  to  inhibit  completion  of  command 
components  at  the  user  terminal,  by  typing  a 
special  character   (instead  of  the  escape  key). 


5.2  Command  Language  Subset 

The  subset  of  functions  selected  for  command  language 
implementation  is  listed  in  Table  2.  A  compact  table  of 
that  form  is  envisioned  to  be  the  minimum  form  of  user  aid 
which  might  be  posted  near  the  user  terminal.  The  user  is, 
of  course,  expected  to  be  able  to  relate  to  the  types  of 
functions  applicable  to  bibliographic  retrieval  systems  and, 
upon  selection  of  the  system  of  interest  and  after 
commanding  the  NAM  to  establish  connection,  e.g.,  with 

CONNECT  TO  SYSTEM  ORBIT  (CR) 
the  user  then  proceeds  to  employ  any  other  available  ' action 
verb/object/    qualifier     commands.       For  examples,  to  select 
from  among  the  repertoire  of    data     bases     accessible     in  a 
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given  system, 

ACCESS  FILE  NTIS  (CR) 
and  then  to  actually  carry  out  a  search, 

FIND  NETWORK  AND  GRAPHICS  (CR) 
To  output  a  specified  number    of    responses    resulting  from 
that  search,  the  user  can  command 

DISPLAY  15  CITATIONS  (CR) 
and  when  some  help  or  explanation  is  desired,  corresponding 
commands  are  available.     Then,  after  perhaps  having  utilized 
various  other  action  commands  identified    in    Table    2,  the 
user  can 

STOP  SESSION  (CR) 
and  thereby  cause  the  NAM  to  carry  out  the  necessary  logout 
and  disconnect  procedure. 

Several  of  the  details  associated  with  Table  2  warrant 
elaboration: 

1.  Automatic  command  completion  applies  to  both  of  the 
following  command  components: 

a.  Action  verbs   (including  alternative  versions) 
collectively,  and 

b.  Within  each  function,  hierarchically  under  the 
set  of  action  verbs,  for  the  set  of  objects. 

Thus,  for  example,  to  carry  out  display  of 
available  filenames,  the  user  would  actually  only 
need  to  type: 

DIS(Esc)   FIL(ESC)  (CR) 
while  the  NAM  would  supply  the  missing 
character  strings  automatically. 

2.  Qualifiers  may  be  required  or  optional,  depending 
on  command  type.  The  NAM  is  easily  prepared  to 
search  for  one  or  more  successive  qualifiers 
succeeding  each  action  verb  and  each  object 
specification.  In  the  interest  of  more  natural 
interaction,  some  reasonable  exceptions  (e.g.,  with 
the  above-stated  DISPLAY  command  involving  the 
numeric  qualifier  "15")   are  possible. 

3.  Certain  qualifiers  must  get  special  separate, 
context-  specific  attention,  e.g.,  the  BOOLEAN 
operators  (AND,  OR,  NOT)  which  are  required  in  the 
term  entry  and  logic  creation  of  the  search 
request. 

4.  The  two  input  editing  functions  are  not  as  yet 
handled  in  a  more  user-oriented  manner  due  to  a 
conflict  between  generally  acknowledged, 
appropriate  characters  and  what  the  NAM  happens  to 
do  with  them.  Perhaps  something  like  Control  E 
(for  last  character  ERASE)  and  Control  I  (for 
IGNORE  or  erase  current  line)  will  be  possible. 


34 


5.5  Implemented  Macros 

Utilizing  the  capabilities  of  the  testbed  facilities 
described  in  Section  4,  and  given  the  detailed  descriptions 
of  command  semantics  and  syntax  pertaining  to  the  five 
available  retrieval  systems,  the  common  command  language 
subset  was  appropriately  specified  and  then  was  implemented 
by  Rosenthal  and  Lucas  [1978] .  The  resulting  macros  are 
displayed  in  Appendix  A  for  two  of  the  systems  used. 


5.6  Demonstration  and  Testing 

The  common  command  language  was  then  informally  tested. 
For  sake  of  consistency,  a  predefined  scenario  of  commands, 
involving  most  of  the  implemented  functions  (See  Table  2)  at 
least  once,  was  employed  in  successively  accessing  and  using 
two  of  the  five  systems.  The  interactive  sessions,  as  seen 
by  the  user  as  well  as  by  the  NAM,  were  recorded  in  detail. 
A  sample  of  each  is  listed  in  APPENDIX  B. 


6.  CONCLUSIONS 

This  report  has  presented  the  framework  for  the 
motivation,  implementation  and  testing  of  an  intermediary, 
"unif ormizing"  processor  of  user-computer  interaction 
languages.  In  particular,  the  NBS  testbed  facilities,  based 
on  the  NAM,  have  been  described  with  primary  regard  to  the 
conceptual  and  logical  capabilities  they  must  possess  in 
order  to  effectively  serve  the  needs  of  on-line  users  of 
bibliographic  information  retrieval  systems. 

As  a  consequence  of  the  informal  testing  and  several 
formal  demonstrations  of  the  described  testbed  facilities, 
the  following  conclusions  are  indicated: 

1.  For  an  application  of  the  type  employed  (i.e., 
bibliographic  retrieval) ,  involving  considerable 
similarities  or  consistencies  among  the  functions 
carried  out  by  different  system  implementations, 
the  uniformizer  role  (of  the  NAM)  represents  a 
"virtual"  form  of  achieving  a  common  or 
standardized  interaction  language.  It  may  be  a 
precursor  to  "real"  standardization  in  the  future. 

2.  The  command  language  subset  presented  gives  a 
reasonably  effective,  first  approximation  of  what 
might  become  a  more  us'er-or  iented  common 
(bibliographic  retrieval)  language.  However,  to 
arrive  at  a  more  complete  and  operationally  usable 
language,  more  detailed  consideration  and 
implementation  of  necessary  or  desirable  functions 
and  options  must  be  carried  out.  This  should  be 
done  in  consultation  with  operational  staff  persons 
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or  information  specialists. 

3.  For  purposes  of  producing  demonstrable  results 
within  a  reasonable  time  period,  various  language 
options  were  implemented  in  minimal  form  or  by 
default.  Much  more  elegant  and  powerful  features 
can  be  incorporated  (with  present  facilities)  and, 
furthermore,  could  be  incorporated  (with  extended 
facilities)  through  committed  efforts  to  further 
NAM  development.  Example  areas  of  attention  would 
be  user/system  profile  creation  and  manipulation  as 
well  as  "adaptability"  to  user  and  system  needs. 

4.  The  framework  and  facilities  described  also  show 
potentials  for  applicability  to  a  number  of  other 
areas  (or  systems)  involving  user-computer 
interaction.  A  good  example  would  be  the  area  of 
text  editing.  Numerous  different  text  editors  are 
available  and  user  access  to  them  could  be 
" unif ormized"  by  identifying  commonalities  in 
function  and  designing  and  implementing  a  common 
text  editing  command  language.  An  NBS  effort  is 
currently  being  initiated  in  this  direction. 
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APPENDIX  A:     Command  Macros 


The  macros,  which  were  designed  and  implemented  for  purposes 
of  uniformly  performing  the  functions  represented  by  the 
common  command  language  subset  on  each  of  the  sample 
bibliographic  retrieval  systems,  are  listed  on  the  following 
pages  for  the  systems  named  ORBIT  and  DIALOG.     The  reader 
may  find  the  indicated  hierarchy  among  the  macros  useful. 
Each  macro  name  is  also  identified  by  page  number  (referring 
to  this  Appendix)   to  easily  locate  it^  listing: 


CONNECT  (page  A2) 

(if  ORBIT  is  selected:  (if  DIALOG  is  selected 

page  A3)  page  A9) 

DISPLAY  (page  A4)  DISPLAY  (page  AlO) 

ACCESS   (page  A5)  ACCESS   (page  All) 

FIND  (page  A6)  FIND  (page  A12) 

HELP  (page  A7)  HELP   (page  A13) 

STOP   (page  A8)  STOP   (page  A14) 


It  is  interesting  to  observe,   for  example,  how  much  more 
work  has  to  be  done  by  the  common  language's  FIND  command 
when  employed  for  the  DIALOG  system  (see  page  A12)  ,  v/ith  its 
SELECT  ann  COMBINE  scenario,  as  opposed  to  the  ORBIT  system 
(see  page  A6) ,  which  already  has  a  command  quite  consistent 
with  the  FIND. 


NOTE:  See  Appendix  B  for  transcripts  of  example  user 
sessions . 


Al 


CONNECT  MACRO 


.string  si  name 

.set  si  to  "  .*  {  'medline'  |  'orbit'  |  'recon'  |  'dialog' 
basis'   }  " 

.set  name  to  userline  @  si 

*if   (  name  =  ) 

.msg  "connect  to  system  <name>" 

.msg  "<name>  :=  medline  |  orbit  |   recon  j  dialog 

basis" 

.exit 

*end 

.newdir  $name. 
connect 


A2 


ORBIT/CONNECT 


.set  connect ionmade  =  0 

.connect  tymnet  orbit  -p  c 

*if  ~  connect ionmade 

.msg  "sorry,  please  try  again" 

. newdir  . . 

.exit 

*end 
. transcr ipt-on 

.term  "t30   !    'identifier"   1    ':'    !    •;•    !  '|'" 

.match      . • " 

.send 

*if  (  response  ?     .  *  •  |  •  "  ) 

.msg  "remote  connection  error   [CR] [LF] 
.msg  "no  response,  please  try  again" 
.disconnect 
.newdir  . . 
.  exit 

*end 

*if  (  response  ?".*' identifier ' "  ) 
.send  "e" 

*end 

*if   (  response  ?  ".*   (   'name'    |    'log  in'   )    "  ) 
.send  "  [CR] " 

*else 

.msg  "remote  connection  sequence  error 

.msg  "please  try  again" 

.disconnect 

. newdir  . . 

.  exit 

*end 

.send  "orbit  [CR] " 
. term  "t60   •    'USER: ' " 

.send  "/login   [CR]  " 

*if  (  response  ?  ".*  'USER:'"  ) 
.send  "n[CR] " 

.msg  "Login  successful   [CR] [LF] " 
.  exit 

*end 

.msg  "Problem  logging  into  ORBIT  [CR] [LF] " 
.msg  response 
.disconnect 
.newdir  .. 


A3 


ORBIT/DISPLAY 


.String  s 
.  int  i 

.term  "t60    !    • user : [CR] [LF] '    !    'USER: [CR] [LF] 
.match  " ' : 

*if  (  userline  ?  ".*   (   'database  names'   |    'file  names'  )   "  ) 
.send  "\"files\" [CR] " 

.msg  response  @  " . *   'PROG:'   {.*}    'SS   '  /0-9/  " 
.exit 

*end 

*if   (  userline  ?  (   'terms'    |    'words'   )"  ) 

.set  s  to  userline  @  'related  to  '{.*}  '[LF]'" 

.send  "\"nbr  "   .   s  .   "\"   [CR] " 

.msg  response  @  'PROG:'   {.*}    'UP  N  OR  DOWN  N? ' 


.send  "0[CR]" 
.exit 

*end 

*if  (  userline  ?  ".*  'citation'"  ) 

.set  i  to  userline  @  ".*  {/-9//0-9/*}  '  citation' 
II 

.send  "\"prt  "   .   i  .  "\"[CR]" 

.msg  response  @  ".*   'PROG:'   {.*}    ' SS   '  /0-9/  " 
.  exit 

*end 

.msg  "display  <object>" 

.msg  "<object>       :=  file  names  [   database  names  |  terms 
related  to  | " 

.msg  "  words  related  to  |   <number  of> 

citations" 

.msg  "<number  of>:=  a  number" 


A4 


ORBIT/ACCESS 


.term  "t60  !  'user : [CR] [LF] •  •  'USER: [CR] [LF] ' 
.match 

.send  "\"file  •'$2\".   "  [CR]  "p 

.msg  response  @  'PROG:'   {.*}    ' SS   '  /0-9/  " 


A5 


ORBIT/FIND 


I  ^  I  II 

I     I  n 


.String  s  ssnopat  ssno  hitspat  hits 

.set  s  to  userline  @  " ' f ind ' { . *} $" 
.set  hitspat  to  'PSTG'.*   '('  {/0-9/.* 

.set  ssnopat  to  'SS'.*   'SS   '  {/0-9/.* 

.term  "tSO   !    'user:\[cr  If]'    !   'USER:\[cr  If 
.match  " • . • " 
.send  s  .   " [CR] " 

.set  hits  to  response  @  hitspat 

*if   (  response  ?  ".*   (    'NONE-'    |    'NP   ('   )    "  ) 
.set  hits  to  "0" 

.set  ssnopat  to  ".*  'SS  •{/0-9/.*l  '  '" 
*end 

.set  ssno  to  response  @  ssnopat 

.msg  "[CR][LF]"  .  hits  .   "  hits  on  "   .  s 
.msg  "Enter  next  search   (#  "   .   ssno  .   "  ) " 


A6 


ORBIT/HELP 


.msg  "you  have  the  following  nam  commands:" 


.msg  "  " 

.msg  "connect  to  system  <name>" 

.msg  "<name>   :=  medline   |  orbit  |   recon  |   dialog   |  basis" 
.msg  "  " 

.msg  "display  <object>" 

.msg  "  <object>         :=  file  names  |   database  names  | 

terms  related  to  ] " 

.msg  "  words  related  to  |   <numher  of> 

citations" 

.msg  "  <number  of>   :=  a  number" 

.msg  "  " 

.msg  "  examples:     display  words  related  to  oil 

embargo" 

.msg  "  display  10  citations" 

.msg  "  " 

.msg  "access  file  <name>" 
.msg  "  " 

.msg  "find  <search  list>" 

.msg  "  example:     find  wheat  and  russia  and  not  china 

.msg  "  " 

.msg  "explain  <command>" 
.msg  "  " 
,msg  "stop" 
.msg  "  " 

.msg  " —  editing  — " 

.msg  "      erase  character  is  control  h   (backspace) " 
.msg  "      erase  line  is  control  u  (nak) " 
.msg  "  " 

.msg  "_  Direct  Host  Communication  — " 

.msg  ".remote  to  communicate  directly  with  host 

.msg  "control  back  arrow    to  return  back  to  the  NAM" 


A7 


ORBIT/STOP 


.term  "t30   !    'user:\[cr  If]'    !    'USER:\[cr  If  ]  '  " 
.match  "'done?'" 

.send  "\"stop\" [CR] " 

.term  "t30   !    'good-bye'    !  'GOOD-BYE'" 
.send  "y[CRl" 

.msg  response  @  ".*  'PROG:'  {.*  'GOOD-BYE'  }  .*  $" 
.  wa  i  t  3 

.disconnect  orbit 
. newd  ir  . . 


A8 


DIALOG/CONNECT 


;  flagO  is  used  only  by  dialog  to  remember  the  last  search 

statement 

;  see  macro  find 

.set  flagO  to  1 

.set  connectionmade  to  0 
.connect  tymnet  dialog  -p 

*if  ~  connectionmade 

.msg  "sorry,  please  try  again" 
. newdir  , . 
.  exit 

*end 
. transcr  iption 

.term  "t30   !    'identifier'    !    ':'    !    'bbbb[CR]'    !  BBBB[CRl'  ! 
.match  "'id'" 
.send  "" 

*if  (  respnse  ?  - . * • |  •  "  ) 

.msg  "remote  connection  error [CR] [LF] " 

.msg  "no  response,  please  try  again" 

.disconnect 

. newd  ir  . . 

.exit 

*end 

*if  (  response  ?  ".*' identifier ' "  ) 
.send  "e" 

*end 

*if   (  response  ?  ".*   (   'name'    |    'log  in'   )    "  ) 
.send  "  [CR]  " 

*else 

.msg  "remote  connection  sequence  error" 

.msg  "please  try  again" 

.disconnect 

. newdir  . . 

.exit 

*end 

.send  "  [CR]  " 

*if   (  response  ?  (   'error'    |    'trouble'    |    'busy'    |  'down' 

)"  ) 

.msg  response 

.msg  "please  try  again" 

. d  isconnec t 

.newdir   . . 


A9 


DIALOG/CONNECT  (continued) 


.  exit 

*end 


*if   (  response  ?  ".*   (   'PASSWORD'    |    'password'    |  'PASSWORD' 

)  ) 


.term  "t60   !    ' ?  '" 
.send  "  [CR]  " 

*if   (  response  ?  " . *   '?   '   "  ) 

.msg  "Login  successful [CR] [LF] " 
.msg  response  @  "  {.*}    '?   '  " 
.exit 

*end 

*end 

msg  "Problem  logging  into  DIALOG [CR] [LF] " 
msg  response 
disconnect 
,  newdir  . . 


A9a 


DIALOG/DISPLAY 


.String  s 
.  int  i 

.term  "tSO   I   '?  ' " 
.match  •"?•" 

*if  {  user  line  ?  ".*   (   'database  names'   |    'file  names'  ) 
.send  "TfilesCCR] " 

.msg  response  @  '?files'   {.*}  '?'" 

.set  scratch  to  response 

.exit 

*end 

*if  (  user  line  ?  ".*   (   'terms'   |    'words'  )   "  ) 

.set  s  to  user  line  @  ".*  'related  to  '{.*}s" 
.send  "expand  "  .  s  .  " [CR] " 

.msg  response  @  '  [CR]  '  {..*}   '-more-'  " 

.exit 

*end 

*if  (  userline  ?  'citation'"  ) 

.set  i  to  userline  @  ".*  {/0-9//0-9/*)  ' 
citation' " 

.send  "type  "  .  flagO  .   "/2/1-"  .   i  .  " [CR] " 
.msg  response  @  ".*  ' [CR] '  {.*}   •?  '  " 
.  exit 

*end 

.msg  "display  <object>" 

.msg  "<object>  :=  file  names  |  database  names  |  terms 
related  to  |" 

.msg  "  words  related  to  |   <number  of> 

citations" 

.msg  "<number  of>  :=  a  number" 


AlO 


DIALOG/ACCESS 


.string  user  filename  systemf ilename  filenumber  scratchl 
.string  namepat  matchpat 

.set  namepat  to  "  {.*}    '  [CR]  '  " 

.term  "tSO   1  '? 
.match  •"?'" 

*if  (  ~   (  userline  ?  "'access  file        )  ) 

.msg  "access  file  <name>" 

.exit 

*end 

.set  user  filename  to  userline  @  "'access  file  '   {.*}   ' [LF] ' 

*if   (  user  filename  =  ""  ) 

.msg  "access  file  <name>" 
•  exit 

*end 

*if   (  userfilename  ?  "/0-9//0-9/*  $"  ) 

.send  "begin  "   .  userfilename  .   " [CR] " 
.msg  response  @  ' [CR] '   {.*}    '?  '" 

.  exit 

*end 

*if   (  ~   (  scratch  ?  ".*   'file'   "  )  ) 
.send  "?files[CR]" 
.set  scratch  to  response 

*end 

.set  scratchl  to  scratch  @  ' : [CR] [LF] '   {.*}  '[CR][LF]?' 

*while   (  scratchl  #  ""  ) 

.set  filenumber  to  scratchl  @  ".*  {/0-9//0-9/*}    '  '" 
.set  systemf ilename  to  scratchl  @  namepat 

.set  matchpat  to  ".*'"   .  userfilename  .  "'" 

*if   (  systemf ilename  ?  $matchpat.  ) 

.send  "begin  "   .   filenumber   .   " [CR] " 
.msg  response  @  ".*   ' [CR] '   {,*)    '?  '" 
.  exit 

*end 

.set  scratchl  to  scratchl  @  ".*   ' [CR] [LF] '   {.*}  $" 

*end 

.msg  "file  "   .  userfilename  .   "  not  found" 


All 


DIALOG/FIND 


.term  "t40   !  •? 
.match  •"?•" 

.string  s  result  key  next  rest  ssno  ssnopat  hits  hitspat 

.set  s  to  userline  @  "'find'   {.*}  '[LF]'$" 

.set  next  to        '*   (  {/a-z//a-z/*}  ( •   'I'ClM'l^)  I 

{•('I  ')•}•)  " 

.set  rest  to        '*  (   (/a-z//a-z/*) ( '   '  1 1  '  ( '  |  ' )  '  1  I $)  I 
(•('I  •)  •)   )   {.*}  $" 

.set  ssnopat  to  " . * ' [CR] ' . *{/0-9//0-9/*} • 

.set  hitspat  to  " . * • [CR] ' . */0-9/. * '    '   {/0-9//0-9/*) '    '  " 

.set  result  to 

*while  s  #  "  " 

.set  key  to  s  @  next 

.set  s  to  s  @  rest 

♦switch  key 

*case 

*case 

*case  "or" 
*case  "and" 
*case  "not" 

.set  result  to  result  .   "  "  .  key 

. break 
*case  "" 

.break 
♦default 

.flush 

.send  "select  "  .  key  .   " [CR] " 
.set  ssno  to  response  @  ssnopat 
.set  result  to  result  .   "  "  .  ssno 
. break 

*end 

*end 

.send  "combine"   .   result  .   " [CR] " 

.msg  (  response  @  hitspat  )  .  "  hits  on  "  .  (  userline  @ 
" 'find'{ .*]$"  ) 

.msg  "Enter  next  search  (#  "  .  (  resonse  @  ssnopat  )  .  ") 
.set  flagO  to  (   (  response  @  ssnopat  )   -  1  ) 


A12 


DIALOG/HELP 


.  msg 

"you  have  the  following  nam  commands:" 

.  msg 

ti  II 

.msg 

"connect  to  system  <name>" 

.msg 

"<name>  :=  medline  |  orbit  |   recon  |  dialog  |  basis" 

.msg 

II  II 

.msg 

"display  <object>" 

.msg 

"               <obiect>        :=  file  names  |  database  names  | 

terms 

related  to  j" 

.msg 

"                                         words  related  to  1   <number  of> 

citations" 

.msg 

"               <number  of>  :=  a  number" 

.msg 

•I  n 

.msg 

"               examples:     display  words  related  to  oil 

embargo" 

.msg 

"                                  display  10  citations" 

.msg 

II  II 

.msg 

"access  file  <name>" 

.  msg 

II  11 

.msg 

"find  <search  list>" 

.msg 

example:     find  wheat  and  russia  and  not  china 

.msg 

II  II 

.msg 

"explain  <command>" 

.msg 

11  II 

.msg 

"stop" 

.msg 

•1  II 

.msg 

" —  editing  — " 

.msg 

"      erase  character  is  control  h  (backspace) " 

.msg 

"      erase  line  is  control  u  (nak) " 

.  msg 

•1  II 

.msg 

" —  Direct  Host  Communication — " 

.msg 

".remote                        to  communicate  directly  with  host 

.msg 

"  control  back  arrow  to  return  back  to  the  NAM" 

A13 


DIALOG/STOP 


.term  "t30   !    'dropped  by  host  system'    !    'DROPPED  BY  HOST 

SYSTEM ' " 

.match 

.send  "logoff [CR] " 

.msg  response  @  'logoff   {.*)    ' tc> '  " 

.wait  2 

.disconnect  dialog 
.newdir  .. 


A14 


APPENDIX  B:     Example  Session  Transcripts 


1.  Following  pages  display  the  dichotomizec!  transcript 
of  a  NAM-  supported  session  conducted  with  the 
ORBIT  retrieval  system.  First  is  the  listing  of 
what  the  user  sees  and  requests  in  interacting  with 
the  NAM,  User-input  commands  are  identified  by  the 
preceding  colon  (:).  Secondly,  the  corresponding 
transactions  between  the  NAM  and  the  remote  system 
are  listed.  To  facilitate  reader  comparison  of  the 
respective  transcripts,  for  purposes  of  observing 
what  the  NAM  reaction  is  to  each  command  entered  bv 
the  user,  the  following  succession  of  "common" 
commands  and  their  corresponding  ORBIT  commands  can 
be  used  as  keys: 


User  Command  Scenar io  Correspond ing  ORBIT  Command 

Connect  to  system  orbit  (dial-up  and  log-in 


The  same  types  of  transcripts  for  the  DIALOG  retrieval 
system  are  introduced  on  page  B7. 


Display  file  names 
Access  file  ntis 
Display  terms  related  to 


procedure) 
"files" 
"file  ntis" 
"nbr  networks" 


networks 
Find  networks  and  graphics 
Display  2  citations 
Stop  session 


networks  and  graphics 

"prt  2" 

"stop" 


Bl 


A  Network  Access  Machine  —  NAM 
tconnect  to  system  orbit 
dialing  8419560 

Phone  connection  to  8419560  established 
logical  connection  orbit  established 

Login  successful 

:display  file  names 

YOU  MAY  ACCESS  THE  ERIC,  CHEMCON,  CHEM7071,  AGRICOLA,  NTIS, 
ORBIT,  TULSA,  INFORM,  GEOREF,  COMPENDEX,  LIBCON/E, 
POLLUTION,  P/E  NEWS,  BIOSIS  PREVIEWS,  MANAGEMENT, 
ACCOUNTANTS,  PNI ,  SSIE,  CRECORD,  PAPERCHEM,  CDI,  DEMO  NTIS, 
GRANTS,  FSTA,  LISA,  BIOCODES,  BI06973,  CBPI,  APILIT,  CIS 
INDEX,  AS I,  CIN  AND  ENERGYLINE  DATABASES.  YOU  ARE  NOW 
CONNECTED  TO  THE  ORBIT  DATABASE. 


taccess  file  ntis 

ELAPSED  TIME  ON  ORBIT:     0.03  HRS. 

YOU  ARE  NOW  CONNECTED  TO  THE  NTIS  DATABASE. 


rdisplay  terms  related  to  netv;orks 


POSTINGS  TERM 


1  NETWORKED  (IT) 

33  NETWORKING  (IT) 

3201  NETWORKS  (IT) 

3  NETWORKS/OS  (IT) 

1092  *NETWORKS  (IT) 


:find  networks  and  graphics 
168  hits  on  networks  and  graphics 
Enter  next  search   (#  2) 
tdisplay  2  citations 


-1- 

AN       -  AD- AO 41  798/OSL 

TI      -  Interactive  Computer  Graphics:     A  Responsive  Planning 

and  Control  Tool  for  DoD  Program  Management 
TNO    -  Research  rept. 

Au      -  Callahan,  Joseph  E. ;  Roberson,  Carlton  F. ;  Perino, 

George,  H.  Jr. 
OS      -  Defense  Systems  Management  Coll  Fort  Belvoir  VA 
PD      -  Jan  77;  56p 


B2 


IS  -  U7720 

PR  -  NTIS  Prices:     PC     A04/MF  AOl 
-2- 

AN  -  AD-A040  763/5SL 

TI  -  Dynamic  Memory  Allocation  for  a  Virtual  Memory 

Computer 

TNO  -  Doctoral  thesis 

AU  -  Budzinski,  Robert  Lucius 

OS  -  Illinois  Univ  At  Urbana-Champaign  Coordinated  Science 
Lab 

PD  -  Jan  77;  149p 

IS  -  U7718 

PR  -  NTIS  Prices:     PC  A07/MF  AOl 


:stop  session 

TERMINAL  SESSION  FINISHED  11/11/77  8:00  A.M.    (PACIFIC  TIME) 
ELAPSED  TIME  ON  NTIS:     0.07  HRS. 
TOTAL  ELAPSED  TIME:     0.10  HRS. 

PLEASE  HANG  UP  YOUR  TELEPHONE  NOW.  GOOD-BYE 
connection  orbit  closed 


B3 


please  log  in: 

error,  type  user  name: 

error,  type  user  name:  sdc 

password : 
p  35 
;<- 

<-YOU  ARE  ON  LINE  L9F 

HELLO  FROM  SDC/ORBIT.      (11/11/77  7:54  A.M.   PACIFIC  TIME) 
YOU  ARE  NOW  CONNECTED  TO  THE  ORBIT  DATABASE. 

ARE  YOU  A  NEW  USER?     IF  YES  ENTER  Y.      IF  NO  ENTER  N  OR  A 
COMMAND. 

USER: 
n 

PROG: 

****CANADIAN  BUSINESS  PERIODICALS  INDEX   ("FILE  CBPI")  NOW 
LOADED 

THRU  1975.     MORE  NEXT  WEEK. 

SS  1  /c? 

USER: 

"files" 

PROG: 

YOU  MAY  ACCESS  THE  ERIC,  CHEMCON,  CHEM7071,  AGRICOLA,  NTIS, 
ORBIT,  TULSA,  INFORM,  GEOREF,  COMPENDEX,  LIBCON/E, 
POLLUTION,  P/E  NEWS,  BIOSIS  PREVIEWS,  MANAGEMENT, 
ACCOUNTANTS,  PNI ,  SSIE,  CRECORD,  PAPERCHEM,  GDI,  DEMO  NTIS, 
GRANTS,  FSTA,  LISA,  BIOCODES,  BI06973,  CBPI,  APILIT,  CIS 
INDEX,  ASI,  CIN  AND  ENERGYLINE  DATABASES.  YOU  ARE  NOW 
CONNECTED  TO  THE  ORBIT  DATABASE. 

SS  1  /C? 
USER: 

"file  ntis" 
PROG: 

ELAPSED  TIME  ON  ORBIT:     0.03  HRS. 

YOU  ARE  NOW  CONNECTED  TO  THE  NTIS  DATABASE. 

SS  1  /C? 
USER: 

"nbr  networks" 
PROG: 

POSTINGS  TERM 

1  NETWORKED  (IT) 

33  NETWORKING  (IT) 


B4 


3201  NETWORKS  (IT) 

3  NETWORKS/OS  (IT) 

1092  *NETWORKS  (IT) 

UP  N  OR  DOWN  N? 

USER: 
0 

PROG: 
SS  1  /C? 
USER: 

networks  and  graphics 
PROG: 

SS  1  PSTG  (168) 


SS  2  /C? 
USER: 
"prt  2" 

PROG: 


-1- 

AN       -  AD- AO 41  798/OSL 

TI      -  Interactive  Computer  Graphics:     A  Responsive  Planning 

and  Control  Tool  for  DoD  Program  Management 
TNO    -  Research  rept. 

AU      -  Callahan,  Joseph  E. ;  Roberson,  Carlton  F. ;  Perino, 

George  H.  Jr. 
PD      -  Jan  77;  56p 
IS      -  U7720 

PR      -  NTIS  Prices:     PC  A04/MF  AOl 
-2- 

AN       -  AD-A040  763/5SL 

TI      -  Dynamic  Memory  Allocation  for  a  Virtual  Memory 

Compu ter 
TNO    -  Doctoral  thesis 
AU      -  Budzinski,  Robert  Lucius 

OS      -  Illinois  Univ  At  Urbana-Champaign  Coordinated  Science 
Lab 

PD      -  Jan  77;  149p 
IS      -  U7718 

PR      -  NTIS  Prices:     PC  A07/MF  AOl 


SS  2  /C? 

USER: 

"stop" 

PROG: 

DONE?  (Y/N) 


USER: 

y 
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PROG: 

TERMINAL  SESSION  FINISHED  11/11/77  8:00  A.M.    (PACIFIC  TIME) 
ELAPSED  TIME  ON  NTIS:     0.07  HRS. 
TOTAL  ELAPSED  TIME:     0.10  HRS. 

PLEASE  HANG  UP  YOUR  TELEPHONE  NOW.  GOOD-BYE 
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2.    Following  pages  display  the  pair  of  transcripts 
resulting  from  an  actual  session  with  the  DIALOG 
retrieval  system.    Again,  as  was  suggested  in  Part  1  of 
this  Appendix,  the  reader  can  easily  observe  the  NAM 
role  by  looking  for  the  following  succession  of  command 
pairs  respectively. 


User  Command  Scenario 
Connect  to  system  dialog 

Display  file  names 

Access  file  6 

Display  terms  related  to 

networks 
Find  networks  and  graphics 


Display  2  citations 
Stop  session 


Corresponding  DIALOG  Command (s) 
(Dial-up  and  log-in 
procedure) 
Files 
Begin  6 

Expand  networks 

Select  networks 
Select  graphics 
Combine  1  and  2 
Type  2/2/1-2 
Logoff 


Note  that  the  user  command  scenario  is  identical  to  that 
used  with  ORBIT  in  Part  1,  except  that  "6"  was  used  in  place 
of  filename  NTIS.    However  the  NAM  can  instead  accept  the 
latter,  search  the  system-provided  list  of  filenames  for  its 
occurrence  and  then  use  the  corresponding  number   (6,  in  this 
case)  in  the  command  transmitted  to  the  remote  system. 
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A  Network  Access  Machine  —  NAM 
rconnect  to  system  dialog 
dialing  5551234 

Phone  connection  to  5551234  established 
logical  connection  dialog  established 

Login  successful 

RECONNECT  File  7  Fri  llnov77  8:29:30 


FILE  19   IS  NOT  WORKING  TODAY. . . 

FILE  48   IS  NOW  FILE  20  FEDERAL  INDEX... 

FILE  47   IS  NOW  FILE  21  FED  IND  WKLY. . . 

FOR  PTS  FILES   REALIGNMENT  SEE  ?PTS 


:display  file  names 

Accessable  files: 

1  ERIC  66-77/OCT 

2  CA  CONDENS  70-71 

3  CA  CONDENS  72-76 

4  CA  CONDENS/CASIA  77-  /VOL87(18) 

5  BIOSIS  PREVIEWS  72-77/OCT 
6*  NTIS  64-77/ISS22 

7  SOCIAL  SCISEARCH  72-77/WK38 

8  COMPENDEX  7 0-7 7 /OCT 
*9  AIM/ARM  67-76/DEC 

10  AGRICOLA  70-77/OCT 

11  PSYCH  ABS  67-77/SEPT 

12  INSPEC-PHYSICS  69-77/ISS20 

13  INSPEC-ELEC  &  COMPUT  69-77/ISS20 

14  ISMEC-MECH  ENGR  73-77/ISS16 

15  ABI/INFORM  71-77/OCT 

16  PTS  MARKET  ABS  72-77/OCT 

17  PTS  WEEKLY  NOV  10,1977 

18  PTS  F&S  INDEXES  72-77/SEPT 

19  CHEM  IND  NOTES  74-77/ISS44 

20  FEDERAL  INDEX  AUG  77 

21  FED  IND  WKLY  NOV  9,  1977 

22  EIS  PLANTS (TYPES  $0.50  EA. )   OCT  77 

23  CLAIMS/CHEM  50-76/DEC 

24  CLAIMS/CHEM  77-77/JULY 

25  CLAIMS/CLASS  JAN77 

26  FOUNDATION  DIRECTORY  JULY77 

27  FOUNDATION  GRANTS  73-77/VOL18  ISS6 

28  OCEANIC  ABS  64-77/SEP  OCT 

29  MET/GEOASTRO  ABS  7 0-7 6 /DEC 

30  CASIA  72-76 

31  CHEMNAME(TM)    398,822  SUBSTANCES 

32  METADEX  6 6 -7 7 /NOV 

33  WORLD  ALUMINUM  ABS  68 -7 7 /OCTOBER 

34  SCISEARCH  74-77/WK38 

35  COMP  DISSERT  ABS  1861-1977/OCT 
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36  LANGUAGE  ABS  7 3 -7 6 /SEP 

37  SOCIOLOGICAL  ABS  63-77/#3 

38  AMERICA:     HIST  &  LIFE  VOL3-14A 

39  HISTORICAL  ABS  VOL19-23B 

40  ENVIROLINE  7 1-7 7 /AUGUST 

41  POLLUTION  ABS  70 -7 7 /MAY 

42  PHARM  NEWS  INDEX  75 -7 7 /OCT 

43  CA  PATENT  CONCORDANCE  72-77/^ UN 

44  AQUATIC  SCI  ABS  JAN- JUL  1975 

45  APTIC  66-77/SEPTEMBER 

46  NICEM  1977 

47  (*offline*) 

48  (*offline*) 

49  PAIS  76-77/BUL. #28-31, FLI.V7#2 

50  CAB  ABS  72-77/SEPTEMBER 

51  FSTA  1969  -  NOV  1977 

52  TSCA  1977  CANDIDATE  LIST 
54  CEC/EXCEP  CHILD  66-77/APR 

56  ART  MODERN  /74-76 

57  CLAIMS/GEM  71-77/SEPT 

59  FROST  &  SULLIVAN  DM2/75-76 

60  USDA/CRIS  75-77/SEPT 

64  CHILD  ABUSE  AND  NEGLECT 

69  ENERGYLINE  71-77/JUNE 

71  ONTAP  TEST 

75  (*offline*) 

81  PTS  US  STAT  ABS 7 1-7 7 /AUG 

82  PTS  US  ANNUAL  TIME  SERIES /OCT  77 

83  PTS  US  REG  TIME  SERIES/JUN  77 

86  PTS  FRN  STAT  ABS  7 1-7 7 /AUG 

87  PTS  FRN  ANNL  TIME  SERIES/OCT  77 


raccess  file  6 

llnov77  8:32:31  User  1067 
$3.57     .051  Hrs  File  7 
$0.41  Tymnet 

$3.98     Estimated  Total  Cost 
File6*:NTIS  64-77/ISS22 


Set  Items  Description   (+=0R; *=AND; -=NOT) 


:display  terms  related  to  networks 


Ref  Index-term 
El       NETWORK  VOICE 


TYPE   ITEMS  RT 


CONFERENCING 


1 
1 
1 
1 
35 


E2       NETWORK  VOICE  PROTOCOL  

E3  NETWORK/440  

E4  NETWORKED  

E5  NETWORKING  

E6  -NETWORKS  

E7  NETWORKS  ANALYSIS  THEORY- 

E8       NETWORKS  SYNTHESIS  


5055 


1 
1 
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PROGRAMMING  LANGUAGE   1 

ElO     NETWORTH   1 

Ell     NETWORTH  COMPUTER 

PROGRAM   1 

E12     NETZ   1 

E13     NETZE   1 

E14     NETZKATEGORIEN   1 

E15     NETZUMLAUF   1 

E16     NETZWERKANALYSEPROGRAMM —  1 

E17     NETZWERKEN   1 

:find  networks  and  graphics 

304  hits  on  networks  and  graphics 

Enter  next  search   (#  3) 

rdisplay  2  citations 

2/2/1 

N77-28015/4ST        NTIS  Prices:     PC  A04/MF  AOl 

Gasplot  -  a  Computer  Graphics  Program  That  Draws  a  Variety 
of  Thermophysical  Property  Charts 

National  Aeronautics  and  Space  Administration.  Lewis 
Research  Center,  Cleveland,  Ohio. 

AUTHOR:     Trivisonno,  R.  J.;  Hendricks,  R.  C. 

D3413B4         Fid:     20M,   9B,   7D,   46,   62B,   99F  STAR1518 

June  77  58p 

Rept  No:     NASA-TN-D-8507 ,  E-8627 
Mon  itor : 18 

D(  jcriptors:  *Computer  programs,  *Thermophysical 

properties,  *Computer  graphics.  Fluids,  Gases,  Fortran, 
Graphs  (Charts),  Plotting,  Univac  1100  series  computers 

Identifiers:  Fortran  5  programming  language,  *Gasplot 
computer  program,  NTISNASA 

2/2/2 

AD-908  249/6ST        NTIS  Prices:     PC  A06/MF  AOl 

Graph i te/Epoxy ,  Boron-Graph ite/Epoxy  Hybrid  and 

Boron/Aluminum  Design  Allowables 

Grumman  Aerospace  Corp  Bethpage  N  Y        (388  847) 

AUTHOR:     Cairo,  Ronald  P.;  Torczyner,  Robert  D. 

Technical  rept.  May  71-June  72 

D3372B4         Fid:     IID,   13M,   13E  GRA17722 

Dec  72  120p 

Contract:  F33615-71-C-1605 

Project:     AF-6169CW,  AF-698CW 

Monitor:  AFML-TR-72-232 


BIO 


Distribution  limitation  now  removed. 

Descriptors:  (*Composite  materials,  *Box  beams). 
(♦Graphite,  Composite  materials),  (*Epoxy  resins,  Composite 
materials),  (*Boron,  Composite  materials),  (*Aluminum 
alloys.  Composite  materials).  Laminates,  Fibers,  Filaments, 
Reinforcing  materials.  Mechanical  properties,  Tensile 
properties.  Compressive  properties.  Stresses,  Modulus  of 
elasticity,  thermal  expansion.  Bolted  joints.  Bonded  joints. 
Mathematical  models.  Mathematical  prediction,  Graphics, 
Computer  programs.  Shear  stresses 

Identifiers:  Aluminum  alloy  6061,  Composite  materials. 
Matrix  materials,  Metals,  Poissons  ratio,  NTISDODXD 

: stop  session 

llnov77  10:07:50  User  1067 
$1.89    0.054  Hrs  File6*  2  Descriptors 
$0.43  Tymnet 

$2.32    Estimated  Total  Cost 

LOGOFF  10:07:53 
<-<-<-<- 

connection  dialog  closed 
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please  type  your  terminal  identifier 
-1011-12  — 

please  log  in:   

password : 

<-<-<-<-tc>        host  is  online 


ENTER  YOUR  DIALOG  PASSWORD 
7  Fri  llnov77  8:29:30 

FILE  19  IS  NOT  WORKING  TODAY... 

FILE  48   IS  NOW  FILE  20  FEDERAL  INDEX... 

FILE  47   IS  NOW  FILE  21  FED  IND  WKLY. . . 

FOR  PTS  FILES  REALIGNMENT  SEE  ?PTS 

?  ?files 

Accessable  files: 

1  ERIC  66-77/OCT 

2  CA  CONDENS  70-71 

3  CA  CONDENS  72-76 

4  CA  CONDENS/CASIA  77-  /VOL87(18) 

5  BIOSIS  PREVIEWS  72-77/OCT 
6*  NTIS  64-77/ISS22 

7  SOCIAL  SCISEARCH  72-77/WK38 

8  COMPENDEX  70 -7 7 /OCT 

9  AIM/ARM  67-76/DEC 

10  AGRICOLA  7 0-7 7 /OCT 

11  PSYCH  ABS  67-77/SEPT 

12  INSPEC-PHYSICS  69-77/ISS20 

13  INSPEC-ELEC  &  COMPUT  69-77/ISS20 

14  ISMEC-MECH  ENGR  73-77/ISS16 

15  ABI/INFORM  71-77/OCT 

16  PTS  MARKET  ABS  72-77/OCT 

17  PTS  WEEKLY  NOV  10,1977 

18  PTS  F&S  INDEXES  72-77/SEPT 

19  CHEM  IND  NOTES  74-77/ISS44 

20  FEDERAL  INDEX  AUG  77 

21  FED  IND  WKLY  NOV  9,1977 

22  EIS  PLANTS (TYPES  $0.50  EA. )    OCT  77 

23  CLAIMS/CHEM  50-76/DEC 

24  CLAIMS/CHEM  77-77/JULY 

25  CLAIMS/CLASS  JAN77 

26  FOUNDATION  DIRECTORY  JULY77 

27  FOUNDATION  GRANTS  73-77/VOL18  ISS6 

28  OCEANIC  ABS  64-77/SEP-OCT 

29  MET/GEOASTRO  ABS  7 0-7 6 /DEC 

30  CASIA  72-76 

31  CHEMNAME(TM)    398,822  SUBSTANCES 

32  METADEX  6 6 -7 7 /NOV 

33  WORLD  ALUMINUM  ABS  68-77/OCTOBER 

34  SCISEARCH  74-77/WK38 

35  COMP  DISSERT  ABS  186 1-1977/OCT 

36  LANGUAGE  ABS  73-76/SEP 

37  SOCIOLOGICAL  ABS  63-77/#3 

38  AMERICA:     HIST  &  LIFE  VOL3-14A 
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39  HISTORICAL  ABS  VOL19-23B 

40  ENVIROLINE  71-77/AUGUST 

41  POLLUTION  ABS  70-77/MAY 

42  PHARM  NEWS  INDEX  75 -7 7 /OCT 

43  CA  PATENT  CONCORDANCE  7  2-77/JUN 

44  AQUATIC  SCI  ABS  JAN-JUL  1975 

45  APTIC  66-77/SEPTEMBER 

46  NICEM  1977 

47  (*offline*) 

48  (*offline*) 

49  PAIS  76-77/BUL. #28-31, FLI.V7#2 

50  CAB  ABS  7 2 -7 7 /SEPTEMBER 

51  FSTA  1969  -  NOV  1977 

52  TSCA  1977  CANDIDATE  LIST 
54     CEC/EXCEP  CHILD  66-77/APR 

56  ART  MODERN  /74-76 

57  CLAIMS/GEM  71-77/SEPT 

59  FROST  &  SULLIVAN  DM2/75-76 

60  USDA/CRIS  75-77/SEPT 

64     CHILD  ABUSE  AND  NEGLECT 
69     ENERGYLINE  71-77/JUNE 
71     ONTAP  TEST 
75  (*offline*) 

81  PTS  US  STAT  ABS71-77/AUG 

82  PTS  US  ANNUAL  TIME  SERIES/OCT  77 

83  PTS  US  REG  TIME  SERIES/  JUN  77 

86  PTS  FRN  STAT  ABS  7 1-7 7 /AUG 

87  PTS  FRN  ANNL  TIME  SERIES/OCT  77 
?  begin  6 

llnov77  8:32:31  User  1067 
$3.57     0.051  Hrs  File7 
$0.41  Tymnet 

$3.98     Estimated  Total  Cost 
File6*:NTIS  64-77/ISS22 


Set  Items  Description   (+=0R; *=AND; -=NOT) 


?  expand  networks 


Ref 
El 


Index-term 
NETWORK  VOICE 


Type  Items  RT 


E2 
E3 
E4 
E5 
E6 
E7 
E8 
E9 


CONFERENCING  

NETWORK  VOICE  PROTOCOL  

NETWORK/440  ■  

NETWORKED  

NETWORKING  

-NETWORKS  

NETWORKS  ANALYSIS  THEORY- 
NETWORKS  SYNTHESIS  

NETWORKS.   FORTRAN  4 


1 
1 
1 
1 
35 


5055 


1 
1 


ElO 
Ell 


PROGRAMMING  LANGUAGE  

NETWORTH  

NETWORTH  COMPUTER 


1 
1 


E12 
E13 


PROGRAM 

NETZ  

NETZE  


1 
1 
1 
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E14  NETZKATEGORIEN  

E15  NETZUMLAUF  

E16  NETZWERKANALYSEPROGRAMM — 

E17  NETZWERKEN  


1 
1 
1 
1 


-more- 


?  select  networks 

1  5055  NETWORKS 
?  select  graphics 

2  4572  GRAPHICS 
?  combine  1  and  2 

3  304  1  AND  2 

?  type  2/2/1-2 
2/2/1 

N77-28015/4ST        NTIS  Prices:     PC  A04/MF  AOl 

Gasplot  -  a  Computer  Graphics  Program  That  Draws  a  Variety 
of  Thermophysical  Property  Charts 

National  Aeronautics  and  Space  Administration.  Lewis 
Research  Center,  Cleveland,  Ohio. 

AUTHOR:     Trivisonno,  R.  J.;  Hendricks,  R.  C. 

D3413B4         Fid:     20M,   9B,   7D,   46,   62B,   99F,  STAR1518 

Jun  77  58p 

Rept  No:     NASA-TN-D-8507 ,  E-8627 
Monitor:  18 

Descriptors:  *Computer  programs,  *Thermophysical 

properties,  *Computer  graphics.  Fluids,  Gases,  Fortran, 
Graphs  (Charts),  Plotting,  Univac  1100  series  computers 

Identifiers:  Fortran  5  programming  language,  *Gasplot 
computer  program,  NTISNASA 


2/2/2 

AD-908  249/6ST 


NTIS  Prices:     PC  A06/MF  AOl 


Graph ite/Epoxy,  Boron-Graph ite/Epoxy 

Boron/Aluminum  Design  Allowables 


Hybrid 


and 


Grumman  Aerospace  Corp  Bethpage  N  Y 


(388  847) 


AUTHOR:     Cairo,  Ronald  P.?  Torczyner,  Robert  D. 

Technical  rept.  May  71-Jun  72 

D3372B4         Fid:     llD,   13M,   13E  GRA17722 

Dec  72  120p 

Contract:  F33615-71-C-1605 

Project:     AF-6169CW,  AF-698CW 

Monitor:  AFML-TR-72-232 

Distribution  limitation  now  removed 


Descr  iptors : 


( *Composite 


mater  ials. 


*Box 


beams) , 
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(*Graphite,  Composite  materials),  (*Epoxy  resins,  Composite 
materials),  (*Boron,  Composite  materials),  (*Aluminum 
alloys.  Composite  materials).  Laminates,  Fibers,  Filaments, 
Reinforcing  materials.  Mechanical  properties.  Tensile 
properties.  Compressive  properties.  Stresses,  Modulus  of 
elasticity.  Thermal  expansion.  Bolted  joints.  Bonded  joints 
Mathematical  models.  Mathematical  prediction,  Graphics, 
Computer  programs,  shear  stresses 

Identifiers:  Aluiriinum  alloy  6061,  Composite  materials. 
Matrix  materials,  Metals,  Poissons  ration,  NTISDODXD 

?  logoff 

llnov77  10:07:50  User  1067 
$1.89     0.054  Hrs  File6*  2  Descriptors 
$0.43  Tymnet 

$2.32     Estimated  Total  Cost 
LOGOFF  10:07:53 


<-<-<-<-tc>      dropped  by  host  system 


B15 


NBS-114A  (REV.  9-78) 


U.S.  DEPT.  OF  COMM. 

BIBLIOGRAPHIC  DATA 

1.  PUBLICATION  OR  REPORT  NO. 

NBS  SP  500-63 

2.<jOv't  Accession  No^ 

iHHI 

SHEET 

4.  TITLE  AND  SUBTITLE 

Computer  Scienc 
A  Testbed  for 

L.UIIi[JULci  illUci 

:e  &  Technology: 

Providing  Uniformity  to  Usey 

clLUIUII   La  1  Ivj  ucivjc:  o 

5.  Publication  Date 

August  1980 

Performing  Organization  Code 

7.  AUTHOR(S) 

Siegfried  Treu 

8.  Performing  Organ.  Report  No. 

q  PFRFriRMING  nRRANI7ATI0N  NAME  AND  ADDRESS 

NATIONAL  BUREAU  OF  STANDARDS 
DEPARTMENT  OF  COMMERCE 
WASHINGTON,  DC  20234 

11.  Contract/Grant  No.  . 

12.  SPONSORING  ORGANIZATION  NAME  AND  COMPLETE  ADDRESS  fstreef.  City,  State,  ZIP) 

Same  as  above. 

13.  Type  of  Report  &  Period  Covered 

Final  ; 

14.  Sponsoring  Agency  Code 

15.  SUPPLEMENTARY  NOTES 

Library  of  Congress  Catalog  Card  Number:  80-600107 

Q  Document  describes  a  computer  program;  SF-185,  FIPS  Software  Summary,  is  attachied. 

I6a  ABSTRACT   (A  200-'word  or  less  factual  summary  of  most  significant  information.    If  document  includes  a  significant  bibliography  or 


literature  survey,  mention  it  here,) 

The  differing  user-computer  interaction  languages,  implemented 
for  conducting  the  same  applications-specific  functions  on  different 
systems,  represent  significant  stumbling  blocks  to  users.  Toward 
alleviating  this  problem  area,  the  use  of  an  intermediary  processor 
to  "uniformize"  interaction  languages  is  presented.    A  framework  for 
such  processing  is  characterized  in  terms  of  the  required  intermediary 
actions  and  the  logical  capabilities  needed  to  perform  those  actions. 
The  testbed  software  facilities,  centered  on  the  NBS  Network  Access 
Machine,  are  then  portrayed.    Throughout,  an  example  application, 
using  a  common  command  language  subset  to  access  five  bibliographic 
retrieval  systems,  is  described. 


17.  KEY  WORDS  (six  to  twelve  entries;  alphabetical  order;  capitalize  only  the  first  letter  of  the  first  key  word  unless  a  proper  name; 
separated  by  semicolons) 

Bibliographic  retrieval  systems;  command  language;  interaction  language; 
language  transformation;  language  uniformity;  user-computer  interaction; 
user-oriented  system  design. 


18.  AVAILABILITY                          [3  Unlimited 
1    1  For  Official  Distribution.  Do  Not  Release  to  NTIS 

fxl  Order  From  Sup.  of  Doc,  U.S.  Government  Printing  Office,  Washington,  DC 
20402 

1    1  Order  From  National  Technical  Information  Service  (NTIS),  Springfield, 
VA.  22161 

19.  SECURITY  CLASS 
(THIS  REPORT) 

UNCLASSIFIED 

21.  NO.  OF 

PRINTED  PAGES 

74 

20.  SECURITY  CLASS 
(THIS  PAGE) 

UNCLASSIFIED 

22.  Price 
$4.00 

USCOMM-DC 


<lU.S.    GOVERNMENT    PRINTING   OFFICE  1980-311-045/209 


NBS  TECHNICAL  PUBLICATIONS 


PERIODICALS 

URNAL  OF  RESEARCH— The  Journal  of  Research  of  the 
lional  Bureau  of  Standards  reports  NBS  research  and  develop- 
nl  in  those  discipHnes  of  the  physical  and  engineering  sciences  in 
ich  the  Bureau  is  active.  These  include  physics,  chemistry, 
ineering,  mathematics,  and  computer  sciences.  Papers  cover  a 
■ad  range  of  subjects,  with  major  emphasis  on  measurement 
ilhodology  and  the  basic  technology  underlying  standardization. 
0  included  from  time  to  time  are  survey  articles  on  topics 
isely  related  to  the  Bureau's  technical  and  scientific  programs, 
a  special  service  to  subscribers  each  issue  contains  complete 
tions  to  all  recent  Bureau  publications  in  both  NBS  and  non- 
S  media.  Issued  six  times  a  year.  Annual  subscription:  domestic 
;  foreign  $16.25.  Single  copy,  $3  domestic;  $3.75  foreign. 

iTE:  The  Journal  was  formerly  published  in  two  sections:  Sec- 
A  "Physics  and  Chemistry"  and  Section  B  "Mathematical 


VIENSIONS/NBS— This  monthly  magazine  is  published  to  in- 
I  in  scientists,  engineers,  business  and  industry  leaders,  teachers, 
Jents,  and  consumers  of  the  latest  advances  in  science  and 
inology,  with  primary  emphasis  on  work  at  NBS.  The  magazine 
blights  and  reviews  such  issues  as  energy  research,  fire  protec- 
I,  building  technology,  metric  conversion,  pollution  abatement, 
jith  and  safety,  and  consumer  product  performance.  In  addi- 
it  reports  the  results  of  Bureau  programs  in  measurement 
idards  and  techniques,  properties  of  matter  and  materials, 
ineering  standards  and  services,  instrumentation,  and 
omatic  data  processing.  Annual  subscription:  domestic  $11; 


iign  $13.75. 


NONPERIODICALS 


inographs — Major  contributions  to  the  technical  literature  on 
ious  subjects  related  to  the  Bureau's  scientific  and  technical  ac- 
ties. 

jndbooks — Recommended  codes  of  engineering  and  industrial 
jctice  (including  safety  codes)  developed  in  cooperation  with  in- 
■.sted  industries,  professional  organizations,  and  regulatory 
|lies. 

^cial  Publications — Include  proceedings  of  conferences  spon- 
bd  by  NBS,  NBS  annual  reports,  and  other  special  publications 
iiropriate  to  this  grouping  such  as  wall  charts,  pocket  cards,  and 
iiliographies. 

|*lied  Mathematics  Series — Mathematical  tables,  manuals,  and 
ilJies  of  special  interest  to  physicists,  engineers,  chemists, 
Ilogists,  mathematicians,  computer  programmers,  and  others 
jiaged  in  scientific  and  technical  work. 

jtional  Standard  Reference  Data  Series — Provides  quantitative 
a  on  the  physical  and  chemical  properties  of  materials,  com- 
'bd  from  the  world's  literature  and  critically  evaluated, 
i/eloped  under  a  worldwide  program  coordinated  by  NBS  under 
authority  of  the  National  Standard  Data  Act  (Public  Law 
B96). 


NOTE:  The  principal  publication  outlet  for  the  foregoing  data  is 
the  Journal  of  Physical  and  Chemical  Reference  Data  (JPCRD) 
published  quarterly  for  NBS  by  the  American  Chemical  Society 
(ACS)  and  the  American  Institute  of  Physics  (AlP).  Subscriptions, 
reprints,  and  supplements  available  from  ACS,  1 155  Sixteenth  St., 
NW,  Washington,  DC  20056. 

Building  Science  Series — Disseminates  technical  information 
developed  at  the  Bureau  on  building  materials,  components, 
systems,  and  whole  structures.  The  series  presents  research  results, 
test  methods,  and  performance  criteria  related  to  the  structural  and 
environmental  functions  and  the  durability  and  safely  charac- 
teristics of  building  elements  and  systems. 

Technical  Notes — Studies  or  reports  which  are  complete  in  them- 
selves but  restrictive  in  their  treatment  of  a  subject.  Analogous  to 
monographs  but  not  so  comprehensive  in  scope  or  definitive  in 
treatment  of  the  subject  area.  Often  serve  as  a  vehicle  for  final 
reports  of  work  performed  at  NBS  under  the  sponsorship  of  other 
government  agencies. 

Voluntary  Product  Standards — Developed  under  procedures 
published  by  the  Department  of  Commerce  in  Part  10,  Title  15,  of 
the  Code  of  Federal  Regulations.  The  standards  establish 
nationally  recognized  requirements  for  products,  and  provide  all 
concerned  interests  with  a  basis  for  common  understanding  of  the 
characteristics  of  the  products.  NBS  administers  this  program  as  a 
supplement  to  the  activities  of  the  private  sector  standardizing 
organizations. 

Consumer  Information  Series — Practical  information,  based  on 
NBS  research  and  experience,  covering  areas  of  interest  to  the  con- 
sumer. Easily  understandable  language  and  illustrations  provide 
useful  background  knowledge  for  shopping  in  today's  tech- 
nological marketplace. 

Order  the  above  NBS  publications  from:  Superintendent  of  Docu- 
ments, Government  Printing  Office.  Washington,  DC  20402. 
Order  the  following  NBS  publications— Fl PS  and  NBSIR's—from 
the  National  Technical  Information  Services,  Springfield,  VA  22161 . 

Federal  Information  Processing  Standards  Publications  (FIPS 
PUB) — Publications  in  this  series  collectively  constitute  the 
Federal  Information  Processing  Standards  Register.  The  Register 
serves  as  the  official  source  of  information  in  the  Federal  Govern- 
ment regarding  standards  issued  by  NBS  pursuant  to  the  Federal 
Property  and  Administrative  Services  Act  of  1949  as  amended, 
Public  Law  89-306  (79  Stat.  1127),  and  as  implemented  by  Ex- 
ecutive Order  11717(38  FR  12315,  dated  May  II,  1973)  and  Part  6 
of  Title  15  CFR  (Code  of  Federal  Regulations). 

NBS  Interagency  Reports  (NBSIR) — A  special  series  of  interim  or 
final  reports  on  work  performed  by  NBS  for  outside  sponsors 
(both  government  and  non-government).  In  general,  initial  dis- 
tribution is  handled  by  the  sponsor;  public  distribution  is  by  the 
National  Technical  Information  Services,  Springfield,  VA  22161, 
in  paper  copy  or  microfiche  form. 


BIBLIOGRAPHIC  SUBSCRIPTION  SERVICES 


following  current-awareness  and  literature-survey  bibliographies 
issued  periodically  by  the  Bureau: 

ogenic  Data  Center  Current  Awareness  Service.  A  literature  sur- 
I  issued  biweekly.  Annual  subscription:  domestic  $35;  foreign 

ijuefied  Natural  (Jas.  A  literature  survey  issued  quarterly.  Annual 
iscription:  $30. 


Superconducting  Devices  and  Materials.  A  literature  survey  issued 
quarterly.  Annual  subscription:  $45.  Please  send  subscription  or- 
ders and  remittances  for  the  preceding  bibliographic  services  to  the 
National  Bureau  of  Standards,  Cryogenic  Data  Center  (736) 
Boulder,  CO  80303. 
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